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

[Chris Knadle]

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.

:-(  Yes and I'm not sure where to start looking to try to make sense of it.

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

Mumble upstream investigated dlvsym() as well, and also discovered that
wasn't going to be a workable option.

If you'd like to read the upstream bug where we've been discussing this and
trying to figure out the right fix:

  https://github.com/mumble-voip/mumble/pull/2124

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

Yes, but IIUC it's slightly worse than that.  AFAIK if Qt gets binNMUed
first Mumble would still break until Mumble was binNMUed.  i.e. without
initializing OpenSSL via the patch I'm currently using for Mumble, it seems
this will break anytime there's been an OpenSSL library rename and the
version Qt is built with and the version Mumble is built with differs.

Answering your question directly: Mumble got binNMUed with OpenSSL 1.0.2d-3
on 2015-11-06 whereby it broke and #804363 reported on the 7th, I uploaded
mumble 1.2.10-3 with the SSL initialization patch on the 11th and that
transitioned to Testing on the 13th, qt4-x11 got binNMUed on the 17th... so
there was an 11-day gap been binNMUs of Mumble vs Qt4.

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

Mumble upstream looked into the -openssl-linked ./configure option for
building Qt (neither Qt4 nor Qt5 source packages in Debian use this today)
but if I understand the situation correctly that won't help; Qt would depend
on one version, Mumble would still depend on the other, and both versions
would still be loaded and the situation would be the same.

  -- Chris

-- 
Chris Knadle
Chris.Knadle at coredump.us