Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, 11 Sep 2018 20:53:28 +0200 Sebastian Andrzej Siewior wrote: > On 2018-09-11 16:11:02 [+0300], Adrian Bunk wrote: > > 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. > > now after what happens I consider this issue (#908567) fixed since the > only affected package by this is fixed. Also adding versioned depends is > not easy as I expected it in the morning without too much mess around > it. > > > cu > > Adrian > > Sebastian > >
Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, 11 Sep 2018 20:53:28 +0200 Sebastian Andrzej Siewior wrote: > On 2018-09-11 16:11:02 [+0300], Adrian Bunk wrote: > > 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. > > now after what happens I consider this issue (#908567) fixed since the > only affected package by this is fixed. Also adding versioned depends is > not easy as I expected it in the morning without too much mess around > it. > > > cu > > Adrian > > Sebastian > >
Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On 2018-09-11 16:11:02 [+0300], Adrian Bunk wrote: > 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. now after what happens I consider this issue (#908567) fixed since the only affected package by this is fixed. Also adding versioned depends is not easy as I expected it in the morning without too much mess around it. > cu > Adrian Sebastian
Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, Sep 11, 2018 at 07:18:28PM +0200, Kurt Roeckx wrote: > > > If this is for a call to SSL_CTX_set_max_proto_version(), you can > > > use 0 instead of TLS_MAX_VERSION. > > > > Good point, thanks. > > > > However as the patch is temporary, I do not think it is worth > > a new upload to change that. > > But maybe you can get upstream to use that instead. Done: https://codereview.qt-project.org/239603 -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, Sep 11, 2018 at 08:14:35PM +0300, Dmitry Shachnev wrote: > Hi Kurt, > > On Tue, Sep 11, 2018 at 07:09:04PM +0200, Kurt Roeckx wrote: > > If this is for a call to SSL_CTX_set_max_proto_version(), you can > > use 0 instead of TLS_MAX_VERSION. > > Good point, thanks. > > However as the patch is temporary, I do not think it is worth > a new upload to change that. But maybe you can get upstream to use that instead. I'm thinking about removing that symbol from the public header, but that would be a 1.2 thing in that case. Kurt
Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
Hi Kurt, On Tue, Sep 11, 2018 at 07:09:04PM +0200, Kurt Roeckx wrote: > If this is for a call to SSL_CTX_set_max_proto_version(), you can > use 0 instead of TLS_MAX_VERSION. Good point, thanks. However as the patch is temporary, I do not think it is worth a new upload to change that. -- Dmitry Shachnev signature.asc Description: PGP signature
Bug#908567: [Pkg-openssl-devel] Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, Sep 11, 2018 at 02:28:02PM +0200, Jonas Smedegaard wrote: > Jan-Marek Glogowski wrote: > > Qt5 is just the first breaking package - I have no idea, how many > > packages use TLS_MAX_VERSION in their code. > > According to https://codesearch.debian.net/search?q=TLS_MAX_VERSION the > following packages mention TLS_MAX_VERSION in source code: > > * fetchmail Should still work > * musescore Has a copy of the header only > * qtbase-opensource-src > * shim Has a copy of the header only > * ncrack Has a copy of the header only > * globus-gssapi-gsi Should still work, only in comment, they don't want TLS 1.3 It really looks like qtbase-opensource-src is the only one that breaks on it. Kurt
Bug#907774: [Pkg-openssl-devel] Bug#908567: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, Sep 11, 2018 at 04:11:02PM +0300, Adrian Bunk wrote: > > Dmitry already implemented my short-term workaround: > https://tracker.debian.org/news/986618/accepted-qtbase-opensource-src-5111dfsg-8-source-into-unstable/ If this is for a call to SSL_CTX_set_max_proto_version(), you can use 0 instead of TLS_MAX_VERSION. Kurt
Bug#908567: Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
On Tue, 11 Sep 2018 at 09:00, Jan-Marek Glogowski wrote: > Am 11.09.2018 um 11:57 schrieb Adrian Bunk: > > > Qt5 is just the first breaking package - I have no idea, how many packages > use TLS_MAX_VERSION in > their code. Only a handful according to https://codesearch.debian.net/search?q=TLS_MAX_VERSION
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
Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
Jan-Marek Glogowski wrote: > Qt5 is just the first breaking package - I have no idea, how many > packages use TLS_MAX_VERSION in their code. According to https://codesearch.debian.net/search?q=TLS_MAX_VERSION the following packages mention TLS_MAX_VERSION in source code: * fetchmail * musescore * qtbase-opensource-src * shim * ncrack * globus-gssapi-gsi * openssl * openssl1.0 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
Am 11.09.2018 um 11:57 schrieb Adrian Bunk: >> 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. Who will patch all the binary packages for buster? Everything in sid that builds against current libssl1.1 and uses TLS_MAX_VERSION will break buster. And if we start patching stuff, who will remember to rebuild and "unpatch" all the packages, once the final libssl11 migrates? IMHO libssl1.1 with the current codebase should move to experimental. For the ABI breakage even with a new package name, until we plan a transition. Otherwise libssl1.1 will probably block a lot of packages. Qt5 is just the first breaking package - I have no idea, how many packages use TLS_MAX_VERSION in their code. And symbol versioning also won't help, as it's no symbol in the shared library sense, but a definition in the header, which would need manual handling AFAIK. openssl-1.1.1~~pre9 $ rgrep TLS_MAX_VERSION | grep ".h:" include/openssl/dtls1.h:# define DTLS_MAX_VERSIONDTLS1_2_VERSION include/openssl/tls1.h:# define TLS_MAX_VERSION TLS1_3_VERSION CU Jan-Marek
Processed: Re: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
Processing control commands: > severity 908567 serious Bug #908567 [libssl1.1] libssl 1.1.1 TLS_MAX_VERSION ABI breakage Severity set to 'serious' from 'important' > severity 907774 serious Bug #907774 [libqt5network5] [libqt5network5] Requires openssl >= 1.1.1 Bug #908557 [libqt5network5] Error while setting the maximum protocol version Severity set to 'serious' from 'important' Severity set to 'serious' from 'important' > block 907774 by 908567 Bug #907774 [libqt5network5] [libqt5network5] Requires openssl >= 1.1.1 Bug #908557 [libqt5network5] Error while setting the maximum protocol version 907774 was not blocked by any bugs. 907774 was not blocking any bugs. Added blocking bug(s) of 907774: 908567 908557 was not blocked by any bugs. 908557 was not blocking any bugs. Added blocking bug(s) of 908557: 908567 -- 907774: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907774 908557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908557 908567: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908567 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
Control: severity 908567 serious Control: severity 907774 serious Control: block 907774 by 908567 On Tue, Sep 11, 2018 at 11:00:00AM +0200, Jan-Marek Glogowski wrote: > Package: libssl1.1 > Version: 1.1.1~~pre9-1 > Severity: important > > 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. 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
Processed: Re: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage
Processing control commands: > severity 908567 serious Bug #908567 [libssl1.1] libssl 1.1.1 TLS_MAX_VERSION ABI breakage Ignoring request to change severity of Bug 908567 to the same value. > severity 907774 serious Bug #907774 [libqt5network5] [libqt5network5] Requires openssl >= 1.1.1 Bug #908557 [libqt5network5] Error while setting the maximum protocol version Ignoring request to change severity of Bug 907774 to the same value. Ignoring request to change severity of Bug 908557 to the same value. > block 907774 by 908567 Bug #907774 [libqt5network5] [libqt5network5] Requires openssl >= 1.1.1 Bug #908557 [libqt5network5] Error while setting the maximum protocol version 907774 was blocked by: 908567 907774 was not blocking any bugs. Ignoring request to alter blocking bugs of bug #907774 to the same blocks previously set 908557 was blocked by: 908567 908557 was not blocking any bugs. Ignoring request to alter blocking bugs of bug #908557 to the same blocks previously set -- 907774: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907774 908557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908557 908567: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908567 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
