Bug#858937: kde4libs: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

On 2018-12-03 12:30:53 [+0100], Didier 'OdyX' Raboud wrote:
> > If you switch to openssl-dev with this upload, please make it depend on
> > libssl1.1 (which does not happen because it does not depend on any symbols)
> > and the you could also close
> > 
> > #913959 [S|  |  ] [src:kde4libs] kde4libs: Build-Depends on libssl1.0-dev
> 
> I've checked thoroughly, and didn't find any package from src:kde4libs which 
> has a relationship with libssl*; so I think this upload at least is no 
> regression in that regard.

The package loads libssl's symbols dynamically and has to dependencies
on libssl1.1 / libssl1.0.2 and I miss it on  a regular basis during
testing.

> Cheers,
> OdyX

Sebastian

Bug#858937: kde4libs: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

On December 1, 2018 2:02:42 PM UTC, Didier 'OdyX' Raboud  
wrote:

>So; to get the ball rolling on this RC bug:
>
>* I've prepared a Debian patch with it 

If you switch to openssl-dev with this upload, please make it depend on 
libssl1.1 (which does not happen because it does not depend on any symbols) and 
the you could also close

#913959 [S|  |  ] [src:kde4libs] kde4libs: Build-Depends on libssl1.0-dev

Thank you for work. Greetings to Bern's BSP team.

>Cheers,
>   OdyX


-- 
Sebastian

Re: Bug#858938: fixed in kopete 4:18.04.1-1

[Sebastian Andrzej Siewior]

On 2018-10-21 12:31:45 [+0200], Kurt Roeckx wrote:
> On Tue, Sep 25, 2018 at 11:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> > > On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > > > Source: kopete
> > > > Source-Version: 4:18.04.1-1
> > > > 
> > > > We believe that the bug you reported is fixed in the latest version of
> > > > kopete, which is due to be installed in the Debian FTP archive.
> > > 
> > > Any plans to upload this to unstable?
> > 
> > There are just two packages left in testing which use openssl1.0. The
> > last kopete upload was in mid June. Is there anything blocking an upload
> > to unstable?
> 
> The other one just got fixed in unstable, so this will soon be the
> only package in testing still depending on libssl1.0.2.

kopete is the only package in testing still using libssl1.0.2. Could
someone please comment on this?

> Kurt

Sebastian

Bug#907427: openssl 1.1.1 breaks ssl tests

[Sebastian Andrzej Siewior]

On 2018-08-27 22:52:06 [+0200], Sandro Knauß wrote:
> Source: qtbase-opensource-src, kimap
> Version: kimap/18.07.90-1
> Control: block 907015 by -1
> 
> When I built my KDE PIM packages locally I built against openssl 1.1.0h-4 and 
> I had no issues running the KIMAP tests.
> With openssl 1.1.1~~pre9-1 (experimental) the tests breaks. See [1] for more 
> examples.
> 
> You may want to merge with #907340 or #907340, as those are also failings 
> tests because of openssl 1.1.1.
> 
> hefee
> 
> [1] https://buildd.debian.org/status/package.php?p=kimap=experimental
> 
> [...]
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "Error 
> loading local certificate, error:140AB18F:SSL 
> routines:SSL_CTX_use_certificate:ee key too small"
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> QAbstractSocket::SocketError(21)
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "Unable 
> to init SSL Context: "
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> QAbstractSocket::SocketError(20)
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) "The 
> remote host closed the connection"
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> QAbstractSocket::RemoteHostClosedError
> QWARN  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> org.kde.pim.kimap: Connection to server lost  0
> FAIL!  : LoginJobTest::shouldUseSsl(any protocol with anyssl version) 
> 'login->exec()' returned FALSE. ()
>Loc: [/<>/autotests/loginjobtest.cpp(250)]

Could you try to increase the keys used in the testsuite to atleast
2048bit? Then it should pass. If that is the case than please unblock
the bug.

Sebastian

Re: Bug#858938: fixed in kopete 4:18.04.1-1

[Sebastian Andrzej Siewior]

On 2018-08-25 10:33:54 [+0200], Kurt Roeckx wrote:
> On Fri, Jun 01, 2018 at 11:22:09AM +, Sandro Knauß wrote:
> > Source: kopete
> > Source-Version: 4:18.04.1-1
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > kopete, which is due to be installed in the Debian FTP archive.
> 
> Any plans to upload this to unstable?

There are just two packages left in testing which use openssl1.0. The
last kopete upload was in mid June. Is there anything blocking an upload
to unstable?

> Kurt

Sebastian

Re: [Pkg-openssl-devel] OpenSSL+Qt interoperability?

[Sebastian Andrzej Siewior]

On 2018-09-11 22:43:26 [+0300], Antti Järvinen wrote:
> buster where this app was still working on Sunday 9th september. On
> 10th apt upgraded libqt5network5:amd64 from 5.11.1+dfsg-6 to 5.11.1+dfsg-7
does 5.11.1+dfsg-8 work for you?
…
> combination that should work? The nodes in the network generally
> handshake with TLS1.2, RSA2048+AES256, it should not be issue with
> obsolete algorithm at least?
no.

Sebastian

Bug#907774: Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Sebastian Andrzej Siewior]

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: [Pkg-openssl-devel] Bug#908567: libssl 1.1.1 TLS_MAX_VERSION ABI breakage

[Sebastian Andrzej Siewior]

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#859853: khtml: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Bug#850897: qca2: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Bug#859671: qtbase-opensource-src: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Bug#859673: qtwebsockets-opensource-src: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Bug#858938: kopete: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Bug#858937: kde4libs: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Bug#828522: qt4-x11: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Bug#850888: kdelibs4support: Please migrate to openssl1.1 in buster

[Sebastian Andrzej Siewior]

Hi,

this is a remainder about the openssl transition [0]. We really want to
remove libssl1.0-dev from unstable for Buster. I will raise the severity
of this bug to serious in a month. Please react before that happens.

[0] https://bugs.debian.org/871056#55

Sebastian

Re: Qt4 in the context of OpenSSL 1.0 removal

[Sebastian Andrzej Siewior]

On 2017-08-26 16:44:34 [-0300], Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! src:qt4-x11 is not listed in the transition but it's definitely using 
> libssl (although trough dllopen).

It is. The other qt-related bugs are:
#828522 [i|  |♔] [src:qt4-x11] qt4-x11: FTBFS with openssl 1.1.0
#859671 [i|  |♔] [qtbase-opensource-src] qtbase-opensource-src: Please migrate 
to openssl1.1 in Buster
#859673 [i|  |♔] [qtwebsockets-opensource-src] qtwebsockets-opensource-src: 
Please migrate to openssl1.1 in Buster

I see those bugs listed as blocker of this bug.

> We have tried a patch proposed in #828522 but sadly whe where hit with:
> 
> 
> 
> At this point we are back at stage 0, either:
> 
> a) We remove SSL support letting lots of apps fail or silently use 
> unencrypted 
> connections.

why silently? I would assume that if the SSL class is not availble that
it won't compile or won't provide a connection at all (say khtml works
only http then).

> b) We remove Qt4 aling all their rdeps.
> 
> Ideally (b) should happen before we release Buster, but I do realize it *will 
> be complicated*. (a) Would be a wonderful way towards achieving (a) actually.

That qgis looks interresting. Do you want me to look at it or do prefer
to use a) as motivation to get people to move to qt5?

Sebastian

Re: Bug#871477: upgrade of libssl1.1 to breaks dovecot imap via tls: kmail from debian stable/unstable cannot connect to dovecot any more

[Sebastian Andrzej Siewior]

On 2017-08-08 12:44:09 [+0200], Wolfgang Walter wrote:
> Package: libssl1.1
> Version: 1.1.0f-4
> Severity: important
> 
> After upgrading a server to libssl1.1 1.1.0f-4 kmail on debian/stable could 
> not connect to dovecot on debian/unstable any more (kmail on debian/unstable 
> can't connect, either).
> 
> Dovecot logs "... tls_process_client_hello:version too low ..."

Is this broken with kmail only or are other clients affected, too?

> Probably this is due to "Disable TLS 1.0 and 1.1".

Yes but why? studlmu.lrz.de:993 handshakes here with TLS1.2. openssl in
previous releases supports TLS1.2. So something limited it to TLS1.0
and/or 1.1 only.

> Please reactivate it. We would like to continue our policy to continously 
> test debian/unstable and debian/testing on servers in our environment. 

Did you limit on kmail side the connection somewhere to TLS1.0 only? If
not, does this help (patch against kio):

diff --git a/src/core/ktcpsocket.h b/src/core/ktcpsocket.h
index 75e1f8c4489a..4ff674d8abc1 100644
--- a/src/core/ktcpsocket.h
+++ b/src/core/ktcpsocket.h
@@ -163,7 +163,7 @@ class KIOCORE_EXPORT KTcpSocket: public QIODevice
 TlsV1_0 = TlsV1,
 TlsV1_1 = 0x40,
 TlsV1_2 = 0x80,
-AnySslVersion = SslV2 | SslV3 | TlsV1
+AnySslVersion = SslV2 | SslV3 | TlsV1 | TlsV1_1 | TlsV1_2
 };
 Q_DECLARE_FLAGS(SslVersions, SslVersion)
 

I Cc qt/kdepim/kio folks in case they have a clue who is limmiting this.

> Regards,

Sebastian

Bug#859853: khtml: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: khtml
Version: 5.28.0-2
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle. It was switched to
libssl1.0-dev in order to follow QT (the bug report was #856004).

Sebastian

Bug#859673: qtwebsockets-opensource-src: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: qtwebsockets-opensource-src
Version: 5.7.1~20161021-4
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#859671: qtbase-opensource-src: Please migrate to openssl1.1 in Buster

[Sebastian Andrzej Siewior]

Package: qtbase-opensource-src
Version: 5.7.1~20161021+dfsg-5
Severity: important
Tags: sid buster
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1-trans

Please migrate to libssl-dev in the Buster cycle.

Sebastian

Bug#856004: khtml: please build-depen on libssl1.0-dev for Stretch

[Sebastian Andrzej Siewior]

On 2017-03-01 00:50:59 [+0100], John Paul Adrian Glaubitz wrote:
> Hi!
Hi,

> The problem is that if the package was to be rebuilt now, it would be
> rebuilt with OpenSSL 1.1 and not OpenSSL 1.0 which is the original
> motivation for this bug report by Sebastian!

it already has been built with 1.1. We are done with the binNMUs for
openssl.

> Adrian

Sebastian

Bug#856004: khtml: please build-depen on libssl1.0-dev for Stretch

[Sebastian Andrzej Siewior]

On 2017-02-26 20:31:23 [+0100], Pino Toscano wrote:
> In data domenica 26 febbraio 2017 20:15:25 CET, John Paul Adrian Glaubitz ha 
> scritto:
> > On 02/26/2017 07:48 PM, Sebastian Andrzej Siewior wrote:
> > > I don't insist on anything. I noticed that this package does not depend on
> > > libssl after building and that is why I took a look.
> 
> That is because it dlopen's libssl at runtime.
> 
> > Interesting. So, I guess the best option would actually to drop the B-D on
> > libssl-dev completely. I have checked it myself and indeed libkf5khtml5 does
> > not depend on libssl at all. Plus, the package also builds fine with the
> > build dependency on libssl-dev completely removed.
> 
> That is because it is an optional dependency.
> 
> > Lisandro, maybe just dropping the build dependency on libssl-dev would be
> > the best option if it's actually not used at all?
> 
> NACK.

Yes, correct. There are a few symbols that export key creation and signing (or
something like that) so if you build this package without ssl then those
symbols are missing which would require a transition :)

Again. If someone who knows that package can say that it works with fine 1.1
and the missing symbols don't matter and it won't clash with 1.0 in any way
then feel free to close this. We are in freeze after all.

Sebastian

Re: Bug#856004: khtml: please build-depen on libssl1.0-dev for Stretch

[Sebastian Andrzej Siewior]

On 2017-02-26 01:03:23 [+0100], John Paul Adrian Glaubitz wrote:
> But the question is whether SSL support is actually relevant in khtml at all.

If it is not exported or mixed with QT's SSL then it is not relevant.

> As you can see from the list of reverse dependencies, there's actually not
> much that is using khtml and the very few packages that use it are offline
> only like SystemSettings or Kiten. So, I don't think any SSL code is actually
> ever used.
> 
> I mean, if you really insist to rebuild khtml with libssl1.0-dev, then please
> just let's go ahead in order to get the number of RC bugs for Stretch down.

I don't insist on anything. I noticed that this package does not depend on
libssl after building and that is why I took a look. Then I noticed it is QT
based and loads symbols which don't exist. If none of that matters then simply
close the bug and keep everything as-is.

> Adrian

Sebastian

Re: Bug#856004: khtml: please build-depen on libssl1.0-dev for Stretch

[Sebastian Andrzej Siewior]

On 2017-02-25 12:29:31 [-0300], Lisandro Damián Nicanor Pérez Meyer wrote:
> I think the issue here is if it will work or not at runtime. 

that is what I assume, correct.

> Sebastian: have you seen it crash due to this?

No. I assume that it might use QT's internal networking which is 1.0 and if
they mix then bad things will happen.
I sure that the following symbols are missing:
 RAND_egd
 NETSCAPE_X509_it
 X509_STORE_CTX_set_chain*
 sk_free*
 sk_num
 sk_pop
 sk_value
 sk_new
 sk_push
 sk_dup
 SSLv23_client_method

The two functions marked * have no error handling if the function is missing.
Not using SSLv23_client_method() means that the the user of this class has to
try again with TLSv1_client_method() member which will only allow a TLS1.0
handshake. This is not what you want because TLS1.0 itself is deprecated and
the v23 method would allow the maximum possible TLS level (which is currently
1.2).
For those reasons I think it is wise to migrate to libssl1.0-dev.

Sebastian

Bug#856004: khtml: please build-depen on libssl1.0-dev for Stretch

[Sebastian Andrzej Siewior]

Package: khtml
Version: 5.28.0-1
Severity: serious

khtml B-D on libssl-dev and has been built against it in the archive. I
am not entirely sure that this works. I doubt because QT itself uses
libssl1.0.2 and passing around SSL, SSL_CTX, BIO or any other struct is
a no no. Additionally some of the symbols, that khtml loads via
dlopen(), are no longer exported by libssl1.1.
Therefore I think it is best to change the B-D to
libssl1.0-dev | libssl-dev (<< 1.1)
for Stretch.

Sebastian

Re: Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]

[Sebastian Andrzej Siewior]

On 2016-10-29 23:26:49 [+0200], Kurt Roeckx wrote:
> On Sat, Oct 29, 2016 at 10:32:34PM +0200, Sebastian Andrzej Siewior wrote:
> > One thing that confuses me: Why has none
> > of the libraries a dependency on libssl?
> 
> From what I understand they use dlopen() and this would allow GPL
> applications to use QT when they don't use OpenSSL. (QT itself
> being LGPL)

Ach right. I though they do some strange symbol hinding with their
define and the q_ prefix but this makes sense. So drom looking at the
code they do only dlopen() so it should all good.

> This is of course potentionally problematic if we have 2 versions
> of openssl that get linked into the same application.

Now that you mention this, #804487 is a proof of something related.

> Kurt

Sebastian

Re: Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]

[Sebastian Andrzej Siewior]

On 2016-08-30 12:40:12 [+0200], Gert Wollny wrote:
> 
> Am Dienstag, den 30.08.2016, 08:51 +0200 schrieb Kurt Roeckx:
> > On Tue, Jun 28, 2016 at 09:53:20PM +0200, Gert Wollny wrote:
> > > 
> > > Thanks for the review. 
> > Can I ask what the current state of this is?
> 
> IIRC the last patch applies properly and compiles with openssl 1.0 and
> 1.1, but since the package doesn't run a test suite at build time I
> have no Idea whether it breaks functionality or not.
> 
> As I pointed out before, I'm neither anopenssl nor a Qt expert, so
> additional reviews of the patch would probably be sensible. 

I've been looking at the patch [0]. It all looks good to me. Most of the
stuff is 1:1 replacement for the accessors. The locking stuff is gone
because the new pthread model that is used renders it unnecessary.
cipher->valid check in resetDefaultCiphers() can be skipped because
openssl returns only valid ciphers not alias ciphers (those have ->valid
set to 0 and are ciphers like "ECDHE" which contain all ciphers that
have something to do with ECDHE but is not an actuall cipher).
So it all looks good to me.

resetDefaultCiphers() tries to add all "openssl DEFAULT" ciphers to its
internal list except for the anonymous DH cipher. Those are not part of
the DEFAULT suite (atleast for 1.0.2 & 1.1.0).

abigail reports no ABI change. One thing that confuses me: Why has none
of the libraries a dependency on libssl?

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522#91

> Best, 
> Gert 

Sebastian

Bug#828522: QT4 and OpenSSL 1.1.0: [was Re: OpenSSL 1.1.0]

[Sebastian Andrzej Siewior]

On 2016-08-30 08:42:07 [-0300], Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! I'm CCing the Qt5 bug too because this concerns both versions.

Could someone please comment if whatever happens in
https://bugreports.qt.io/browse/QTBUG-52905
is related to what happens here?

Sebastian