On Sun, Mar 13, 2016 at 6:20 PM, Chris Knadle <chris.kna...@coredump.us> wrote: > Mikkel Krautz: >> On Sun, Mar 13, 2016 at 2:58 PM, Kurt Roeckx <k...@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?