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

[Kurt Roeckx]

On Sun, Mar 13, 2016 at 01:57:23PM +0100, Mikkel Krautz wrote:
> 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*?

We clearly don't test that upstream, and we'll probably say that
it's not supported.

But like I said, it should work, and since the symbol versioning
was added I never had someone report problems, except when using
dlopen().  With the symbol versioning they both have their own
copy of the global variables.  It should work, but I can't make
any guarantee.

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.


Kurt