On 29 Mar 2010, at 20:20, David Schwartz <[email protected]> wrote:
Mark Phalan wrote:
I'm just suggesting a compile-time option. The application could
always
set the locking callbacks back to NULL if it knew what it was doing.
-M
I think this fix is actually a bad one.
I'm still not clear why you think that.
Will existing libraries continue to
not set the locking callbacks and fail horribly if the system
OpenSSL isn't
compiled with this flag?
Or will they set sane locking callbacks to be safe
-- making this fix a no-op?
Even without the proposed change libraries should at least check
before clobbering the existing callbacks. Checking before setting will
be racy but still better than blindly replacing callbacks.
The proposal doesn't make anything worse it 1) removes the race if
libraries set the callbacks properly and 2) fixes MT issues if they
don't.
Of course there is always the problem of what happens on dlclose() of
the lib if the callbacks are set...
The issue is that existing code may set the locking callbacks badly
and the
horse has already left the stable (we can't redesign them).
We can't easily get all the libraries which might end up eventually
loading OpenSSL to change their APIs so that locking callbacks can be
set but I think it wouldn't be too difficult to get them to do a check
for existing callbacks before doing the set.
Libraries which don't set the callbacks immediately become MT safe (as
far as OpenSSL calls are concerned).
I don't see how
this helps in that case -- the existing code will continue to set the
locking callbacks badly, overriding the sane default.
Indeed. Until those are changed they will be broken both now and
after the proposed change. The proposal offers a sane way out.
-M
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
