Bug#907774: [Pkg-openssl-devel] Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, Sep 11, 2018 at 02:57:17PM +0200, Sebastian Andrzej Siewior wrote: > On 2018-09-11 12:57:17 [+0300], Adrian Bunk wrote: > > > I'm on buster and with the latest updates from yesterday came > > > qtbase-opensource-src 5.11.1+dfsg-7 > > > and SSL started to fail in Qt5 programs. This was reported in bug 907774 > > > ~ 2 weeks ago. > > > > > > Basically libssl 1.1.1 (in whatever 1.1.1 version - my guess is > > > 1.1.1~~pre9-1 from the changelog) > > > changed the definition of TLS_MAX_VERSION from TLS1_2_VERSION to > > > TLS1_3_VERSION, which will start to > > > break all software in buster using that symbol, until libssl1.1 moves to > > > buster. > > > > I'd say that at least for the SSL_CTX_ctrl() symbol the created > > dependency has to be increased. > > > > Raising the severity of both bugs to RC to make the problem more visible, > > and to avoid further duplicate bugs. > > > > Since the new OpenSSL won't enter buster anytime soon, the reasonable > > short-term workaround for testing would be an upload to use > > TLS1_2_VERSION instead of TLS_MAX_VERSION in qtbase-opensource-src. > > So hmm. If I increase the version for the symbol then your new upload of > QT won't migrate to testing because it will depend on openssl which > currently won't migrate. >... > Now. Any suggestions on how to handle this? Dmitry already implemented my short-term workaround: https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/ When this has been built on all release architectures openssl can bump the version requirement. Even more cautious would be to wait until testing migration of Qt. > Sebastian cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#907774: [Pkg-openssl-devel] Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On 2018-09-11 12:57:17 [+0300], Adrian Bunk wrote: > > I'm on buster and with the latest updates from yesterday came > > qtbase-opensource-src 5.11.1+dfsg-7 > > and SSL started to fail in Qt5 programs. This was reported in bug 907774 ~ > > 2 weeks ago. > > > > Basically libssl 1.1.1 (in whatever 1.1.1 version - my guess is > > 1.1.1~~pre9-1 from the changelog) > > changed the definition of TLS_MAX_VERSION from TLS1_2_VERSION to > > TLS1_3_VERSION, which will start to > > break all software in buster using that symbol, until libssl1.1 moves to > > buster. > > I'd say that at least for the SSL_CTX_ctrl() symbol the created > dependency has to be increased. > > Raising the severity of both bugs to RC to make the problem more visible, > and to avoid further duplicate bugs. > > Since the new OpenSSL won't enter buster anytime soon, the reasonable > short-term workaround for testing would be an upload to use > TLS1_2_VERSION instead of TLS_MAX_VERSION in qtbase-opensource-src. So hmm. If I increase the version for the symbol then your new upload of QT won't migrate to testing because it will depend on openssl which currently won't migrate. This MAX version probably affectes not only QT. There are a couple of bugs blocking on the other openssl bug which forbids migration. Most of them are "run time errors" because the key or signature is too small. All of them should be fixed and are mostly testsuite. Keys which can't be fixed because of $reason should alter their .cnf. According to Kurt there are few packages broken because they don't send SNI anymore. This is probably worth fixing before migration to testing. Now. Any suggestions on how to handle this? > cu > Adrian Sebastian
