[openssl-users] Openssl static build linked in DLL does not unload on win32
matt at openssl.org
Fri Jan 6 17:02:53 UTC 2017
On 06/01/17 16:37, Michael Wojcik wrote:
>> Can you not link against the OpenSSL DLLs rather than statically
>> link? That would avoid the problem.
> It introduces other problems. It means either shipping the OpenSSL
> DLLs or requiring the customer provide them; the former can have
> legal implications (cryptographic export licensing, for example),
> while the latter is a usability issue. It means the calling library
> no longer controls what version of OpenSSL is used, since the DLLs
> can be replaced.
> I haven't looked at the 1.1.x source to see what OPENSSL_cleanup is
> doing, but it certainly sounds like a bad idea. What kind of cleanup
> needs to happen at process exit (in the typical environment in which
> OpenSSL is used)? I suppose I'll have to take a look at the source,
> but I'd be very interested to hear the rationale.
The problem is that OpenSSL uses global state extensively. Additionally,
you may get more than one component of an application using OpenSSL at
the same time, e.g. the application could use it, as well as libraries
that the application is linked against. In OpenSSL <1.1.0 we had (lots
of) explicit cleanup routines. This was a problem in this scenario
because you could end up with one component cleaning stuff up that
another component was still using.
Initially our atexit cleanup was nicer and got called when the last
reference to OpenSSL got unloaded. However, while this worked nicely on
some platforms, it wasn't portable and caused problems (crashes).
There's a long discussion on the problem and some of the solutions we
looked at here:
and more briefly here:
An example of the issue we were trying to solve is here:
I'm wondering whether an option to override the default behaviour might
be possible, e.g. an explicit call to OPENSSL_init_crypto() with
something like an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The application
would then have to call OPENSSL_cleanup() explicitly. This brings back
all the same problems with multiple components all using OpenSSL - but
perhaps you know this isn't a problem for your particular application
(especially if you are using static linking).
More information about the openssl-users