[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 8:06 PM, Kurt Roeckx <kurt at roeckx.be> wrote:
> On Sat, Mar 12, 2016 at 04:56:22PM +0000, Chris Knadle wrote:
>> > 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.
>
> If nothing uses dlopen(), the symbol versioning should work as far
> as I know, and you things should work.  You would also be binNMUd
> around the same time.

What I meant by "won't help" is that the final Mumble + Qt combination
would still be using different versions of libssl/libcrypto in that
configuration.
I had hoped that something (either Debian packaging tools or ld-linux.so)
would have prevented such a situation. :-)

My fear with having multiple copies of libssl/libcrypto in the same address
space is that something rubs OpenSSL the wrong way and breaks in
a subtle way.

>From a technical point-of-view, nothing should break. The only plausible
way that something would break that I can think of, is if something in
OpenSSL "pollutes" a process-global namespace in some way, such that
some behavior in the "other" OpenSSL copy is affected. I don't know if
that's the case (I assume not), but that's my worry about having two
copies in memory: I don't believe it is something OpenSSL upstream tests,
so who knows if it actually *works*?