[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 6:20 PM, Chris Knadle <Chris.Knadle at coredump.us> wrote:
> 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.
>
> Yes.
> If there's a way of loading libssl/libcrypto "directly", i.e. outside of Qt
> loading it with dlopen(), that should handle this issue.  Is this possible
> and still have it available to QtNetwork?
>
> It probably still makes sense to report this to to the maintainers of Qt
> concerning the -openssl-linked ./configure option regardless.
>
>> 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).
>
> I want to point out what I think the consequences of this choice will be if
> I used the patch today and assuming the Qt source packages aren't rebuilt
> using -openssl-linked.
>
> When a new OpenSSL comes down containing a library rename, the Mumble #2124
> patch will disallow multiple libssl/libcrypto load and Mumble will break.
> Besides Mumble not being functional, the broken behavior deletes the user's
> SSL key used with Mumble and the automatic backup of it, replacing the
> latter with an empty file.  This harms the user's trust and represents a bug
> of severity "grave".
>
> Assuming a user reports the breakage, the only available fix I could give
> would be to have the user downgrade the package and put it on hold (to keep
> it from upgrading) to get a version that was compiled with the prior
> libssl/libcrypto.  Anybody compiling the Mumble package during this time
> will also find it broken when they load and run it.  When Qt gets binNMUed
> the package a user downgraded will break this way again, and the user must
> un-hold and upgrade Mumble to get it to work.
>
> If this ends up being the plan, it's too much to ask.

Sorry. I was under the impression that if we could solve the metadata
problem, this whole thing would be a non-issue:

Quoting Kurt Roeckx:
> 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.

Is this not possible without using -openssl-linked?