> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of > Matt Caswell > Sent: Friday, 30 June, 2023 07:36 > To: Frank Gross <frank.gross@xxxxxxx>; openssl-users@xxxxxxxxxxx > > I've seen "bad things" happen with two different versions of OpenSSL loaded > at the same time. Usually I've seen it where statically linked OpenSSL is used as > well as a dynamically linked OpenSSL (as opposed to two different dynamically > linked versions of OpenSSL being loaded) We build OpenSSL as loadable code (so using, for example, -kPIC on ELFin platforms), but as static libraries. Those are then linked with our own source file which wraps OpenSSL APIs in other functions, to change the public names and also in some cases to add functionality. That becomes a dynamic library / shared object, and we restrict the visibility of entry points to our own (using a list generated at build time from our public header or from filtering the symbols in the object files – both approaches have been used over the years). Then our OpenSSL-consuming code calls our API. This approach has worked well since at least the 1.0.1 days (I don't remember if we did it for 0.9.8), across a wide range of platforms, every sort of third-party thing loaded (implicitly or explicitly) into the same product. Database drivers, LDAP client libraries, customer application modules, etc. It's more work, but it ensures that "your" OpenSSL 1) is never confused with any other build of OpenSSL by your own code, and 2) is never called by anything else (barring malice or Undefined Behavior). -- Michael Wojcik
