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

[Kurt Roeckx]

On Sat, Mar 12, 2016 at 01:04:12AM +0000, Chris Knadle wrote:
> Discussions with mumble upstream about this problem have continued, and the
> situation seems much more muddied than I previously knew.  This is likely
> not an OpenSSL issue per se but rather seems to be an issue whenever OpenSSL
> ships renamed libssl and libcrypto files for soname changes.
> 
> Mumble links against OpenSSL but it seems Qt actually loads the libssl
> librar(y|ies) via dlopen().  [In the link below see lines 634-654 concerning
> SHLIB_VERSION_NUMBER.]
> 
> 
> https://github.com/qtproject/qtbase/blob/dev/src/network/ssl/qsslsocket_openssl_symbols.cpp#L624-L727
> 
> Mumble has broken before in the past for the same reason:
> 
>    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623596#33
> 
> 
> The "big" question is this:
> 
>    If Mumble starts and two different copies of libssl and libcrypto
>    are loaded into memory and initialized, is that okay?

Having 2 versions of the same library loaded and having that work
is non-obvious.  It's using symbol versioning to try to deal with
this, so it should try to use the correct symbols.  But that
probably doesn't work with dlopen().  If this needs to work with
dlopen() you probably need to know which version of the symbols
you want and then use dlvsym().

The problem with dlvsym() is that you then would need to know
which version of the symbol you want.  We currently don't have a
way to tell applications which symbol uses which version.  I'm not
sure why I used OPENSSL_1.0.2d and not just OPENSSL_1.0.2.  I was
thinking about suggesting "OPENSSL_" + SHLIB_VERSION_NUMBER.  In
the next upstream version, we'll actually have files that have the
version per symbol, so I could consider shipping those, but then
it's probaly unlikely that other distros will.

Anyway, I try to avoid having multiple version of the library in
any release in Debian to avoid this problem, and the old version
was removed from testing some time ago already.  I guess you had a
problem because Qt wasn't rebuild yet?

Maybe Qt should have some way to indicate what version it's build
against so that we can binNMU it with all the other packages?   Or
maybe Qt should just link against it, instead of doing dlopen()?


Kurt