[Pkg-openssl-devel] Bug#908567: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Adrian Bunk]

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