On Thu, 24 Nov 2016, Kurt Roeckx wrote: > I've always had the impression that there are or used to be > probems using using dlopen()/dlsym(). Maybe related to some things > like RTDL_GLOBAL that causes the symbol lookup to go to the wrong > library. Do you know of any problems related to that?
AFAIK, OpenSSL itself -- at least as packaged by Debian -- should not get confused about where its *own* static globals are. And any globals it might export would also be fully ELF-symbol-versioned from what I can see (objdump -tT). If RTDL_GLOBAL is borking ELF symbol versioning, all bets are off. Note: I have no idea what happens if you throw libssl.a into the mix with a different version of libssl.so. This kind of hell-born braindamage can happen due to glibc nss modules, for example. > Note that QT is one of those that uses dlopen()/dlsym() when > calling openssl functions (for license reasons). No comment I could make about this would be acceptable in polite company. Or in impolite company. Or even during a sailor-class-cursing competition. > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it > > might not be safe. If it doesn't (i.e. at most you have a qt flag that > > says "use SSL", etc), then it should be fine. > > It seems to be doing this in qtbase5-private-dev. Not sure if > there are actually any users of it. If it does, all reverse *build* dependencies would need to be inspected, then. AFAIK, that means they must not link to anything that could link to a different libssl than the one used by qt5. If they do, everything needs to be inspected down to the details to ensure nothing will ever leak openssl contextes and data structures across a library boundary (including the application). -- Henrique Holschuh
