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

[Mikkel Krautz]

On Sun, Mar 13, 2016 at 3:22 PM, Mikkel Krautz <mikkel at krautz.dk> wrote:
> 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.
>
> 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).

A tiny bit of follow-up to my suggestion of using "-openssl-linked" for Qt:

In the earlier Debian bug that was linked by Chris, it was brought up
that an application may use QtNetwork without using SSL, and therefore
might not be able to link against OpenSSL due to license
incompatibilities:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623596#94

So I suppose the best choice is to:

1. Fix Qt's dynamic loading of OpenSSL such that it only attempts to
load shared libraries compatible to the headers it was built against.
2. Add packaging metadata to reflect that QtNetwork needs a rebuild
when libssl/libcrypto changes (or only for ABI changes?)