Openssl 3.0 / Openssl 1.1 at the same time in the same process

[Viktor Dukhovni]

On Fri, Jun 30, 2023 at 09:26:47AM -0400, Viktor Dukhovni wrote:

> > But
> > the process can also load dynamically (via configuration) database
> > client drivers installed on a computer. (Mainly to perform secure
> > connection with the database engine). But those database drivers are
> > linked with the openssl version of the system. That is mainly openssl
> > version 1.1.
> 
> See:
> 
>     https://github.com/openssl/openssl/blob/55d3a6be6ba3af9781631e74833ea1dcbd4008e6/Configurations/README.md?plain=1#L129-L149
> 
> This allows you to:
> 
>     - Not have to resort loading the custom libssl at runtime, you
>       can just use a shared library.
> 
>     - Avoid conflicts even with a slightly different system libssl
>       that has the same major version.
> 
> Choose the variant name carefully, something related to your
> company or product, not likely to be chosen by another package.

Since you're getting three conflicting responses, I should perhaps
explain that the "Configure" option "shlib_variant=<...>" was
specifically designed to address use of multiple OpenSSL shared library
versions within a single process.

On ELF-based systems, it works provided symbol versions are supported by
the runtime link editor (ld.so), and that OpenSSL is not also linked in
statically.

If you link OpenSSL into a wrapper shared library of your own, and
don't export the OpenSSL symbol from that shared object, that'll
also work, but takes more work to implement.

And of course, as Matt noted, some care is required, so all three
answers are right in their own way.

-- 
    Viktor.