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

Reply via email to