[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 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).