[Pkg-openssl-devel] Bug#804487: Bug#804487: openssl_1.0.2d-3 breaks mumble and mumble-server after binNMU

[Chris Knadle]

Mikkel Krautz:
> On Sun, Mar 13, 2016 at 2:58 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
>> I would also like to say again that if we can somehow see in the
>> meta data that they are using libssl, they would get rebuild at
>> the same time and you wouldn't get into this situation that they
>> are using a different version.
> 
> My vote is also 100% for doing that. Preferably via '-openssl-linked'.
> 
> I actually think the OpenSSL loading code in
> https://github.com/qtproject/qtbase/blob/dev/src/network/ssl/qsslsocket_openssl_symbols.cpp
> for Unix is dangerous:
> 
> Qt itself is built against one set of headers, but the code loading
> OpenSSL dynamically could potentially -- per my reading, at least --
> load a version of OpenSSL that is ABI incompatible with the headers
> used when building Qt.
> 
> If that is the case, the only "safe" way to use Qt without
> "-openssl-linked" is to ensure that it *only* loads libraries that are
> ABI compatible with the headers used at build-time. But it doesn't
> seem to do that, per my reading.
> 
> I hope I'm missing something.
> 
> With that in mind, I don't think it makes sense to ever use the
> dlopen() functionality for loading OpenSSL in QtNetwork. If it only
> ever can load an ABI compatible OpenSSL, it shouldn't need to
> dynamically load it. Especially not in a Linux distro.

Yes.
If there's a way of loading libssl/libcrypto "directly", i.e. outside of Qt
loading it with dlopen(), that should handle this issue.  Is this possible
and still have it available to QtNetwork?

It probably still makes sense to report this to to the maintainers of Qt
concerning the -openssl-linked ./configure option regardless.

> I'll move ahead with the Mumble PR to disallow multiple OpenSSL shared
> libraries in Mumble's address space.
> (https://github.com/mumble-voip/mumble/pull/2124/files).

I want to point out what I think the consequences of this choice will be if
I used the patch today and assuming the Qt source packages aren't rebuilt
using -openssl-linked.

When a new OpenSSL comes down containing a library rename, the Mumble #2124
patch will disallow multiple libssl/libcrypto load and Mumble will break.
Besides Mumble not being functional, the broken behavior deletes the user's
SSL key used with Mumble and the automatic backup of it, replacing the
latter with an empty file.  This harms the user's trust and represents a bug
of severity "grave".

Assuming a user reports the breakage, the only available fix I could give
would be to have the user downgrade the package and put it on hold (to keep
it from upgrading) to get a version that was compiled with the prior
libssl/libcrypto.  Anybody compiling the Mumble package during this time
will also find it broken when they load and run it.  When Qt gets binNMUed
the package a user downgraded will break this way again, and the user must
un-hold and upgrade Mumble to get it to work.

If this ends up being the plan, it's too much to ask.

I'm trying to figure out how to explain the -openssl-linked issue to the
maintainers of qt4-x11 and qtbase-opensource-src; and depending on one's
point of view it could be a bug of severity "wishlist" to "important".

   -- Chris

-- 
Chris Knadle
Chris.Knadle at coredump.us