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

[Mikkel Krautz]

On Sat, Mar 12, 2016 at 11:38 AM, Kurt Roeckx <kurt at roeckx.be> wrote:
> 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().

Hmm. Is the situation really that bad?

Mumble is directly linking against libssl/libcrypto. Qt is dlopen()'ing
the version that SHLIB_VERSION_NUMBER was set to when Qt
was built (but will fall back to other versions if they're available).

Will this really cause confusion for ld-linux.so? It seems to me that
it should be able to distinguish symbols from the two (four?) libraries
without using dlvsym? Qt is explicitly using dlsym() with a handle to
a specific version of libssl/libcrypto.

I say this with reference to the PR on GitHub where this discussion started:
https://github.com/mumble-voip/mumble/pull/2124/files

It seems to me that I should be able to quite clearly look up the
symbols separately for each library without dlvsym():

1. Find the struct link_map for the library
2. Use lm->l_ld (Elf_Dyn *) to find the symtab.
3. Iterate the symtab to find the address for the function
    for that specific library.

> 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()?