Which is essentially what we did at IBM to resolve this - but - closed
ecosystem. It was a lot easier.
What you could do ....
Provide system default callbacks, allow them to be overridden at most once
ONLY if it's done before OpenSSL is usable - i.e. before any
OpenSSL_add_all_algorithms() type calls are made.
Document that this can only be done from the top level executable NOT from
a shared library - and the top level app can switch the lock model if it
wants. Changing the locking model is something that really can only be done
by whatever owns main() anyway - it's not something that can ever be safe
in a shared library.
Peter
From: "David Schwartz" <[email protected]>
To: <[email protected]>, <[email protected]>
Date: 31/03/2010 09:21 PM
Subject: RE: libcrypto safe for library use?
Sent by: [email protected]
Mark Phalan wrote:
> Imagine the above case happening in one thread while another thread
> makes a similar seemingly innocuous call with a similar effect (dlopen
> a
> library which uses OpenSSL). What should pkinit and the second library
> which uses OpenSSL do? If they set callbacks they'll be racing against
> each other. If they don't they will not be MT safe.
> The application never sets the callbacks because as far as it's aware
> it's only calling POSIX APIs.
If we're talking about existing code, they *must* already set callbacks,
otherwise they're hopelessly broken. Since the setting of callbacks will
unsafely override the set defaults, the suggested fix (to default to
callbacks suitable for the platform's default threading model) actually
will
*not* fix this case. If this is the case we care about, why implement a fix
that won't fix this case?
The purported advantage of this fix is that it solves the "horse has
already
left the stable" case where we aren't willing to change the libraries that
call OpenSSL. But it doesn't fix that case.
The only way to fix that case that I can think of is for OpenSSL to start
out using callbacks that are safe for the platform's default threading API
and to ignore, but report success, on all attempts to change the locking
callbacks. That may actually be the right behavior for the existing API.
(And, of course, OpenSSL would implement a newer, better API that new
applications and libraries should use that would include reference counting
and being informed of the threading model in use.)
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
