You can't "push and pop" the callbacks.
The software is running in multiple threads and being used by multiple
independently developed libraries at the same time.
Do you really plan to swap the thread locking mechanism - (which is
protecting you while you swap the locking mechanism around) while threads
are running ?.
I hit this with IBM's bastard son of OpenSSL a few years back - the only
viable fix I could come up with was to internalize the callbacks and set
them to the OS default.
I agree there will be some users who want to use their own threading model
and that should be catered for but I don't think it should be the default
now.
Making the old behaviour a compile time option still works for closed
ecosystem users - but for most end users - i.e. on the Linux's or BSD's
having OpenSSL defaulting to sane and safe system locking is the best
solution I can come up with.
The memory callbacks have the same issue in that only one "caller" in the
process can set them sanely - though those at least default to system
default malloc()/free() so everyone leaving them alone works.
We don't have that option with the thread callbacks - they must be set, but
there's no safe way for multiple "users" in the same process to do that at
present - all I'm suggesting is that you "fix" this in the same way the
memory callback use is made safe.
Peter
On Mon, Mar 29, 2010 at 12:03 AM, Peter Waltenberg <pwal...@au1.ibm.com>
wrote:
I don't think that's an issue anymore - threading is the common case now.
common case != everybody
But - there's another issue you've all missed. You can have multiple
independently developed libraries in the same process all using OpenSSL -
who gets to set the thread callbacks ?. They have to be set to ensure
thread safe operation, but no individual library can assume that "someone
else" has done it now.
Even better - a library does set the callbacks - and gets unloaded while
other libs are still using OpenSSL. (Not just a "what if" - that one I've
seen in the wild).
Even if OpenSSL would submit to your wish, then that would /not/ fix your
failure scenario above. At least not for everybody who needs to replace
that 'default implementation', whatever it will be.
The proper way to fix that kind of conundrum (at least one of the ways and
IMO the most feasible for OpenSSL) is to allow callers (= other libs and
app using OpenSSL) a way to replace-and-restore those callbacks. push and
pop if you will, but I'd rather see that bit of management done by the
outside world (from the perspective of OpenSSL as a highly portable lib).
So that would be an API where you either
a) have an extra API function which delivers the references to the
currently installed callbacks (NULL if none are set up), or
b) a kinda signal() style API function set up where the function which is
used to register those callbacks with OpenSSL returns a reference to the
previously installed callback.
Both ways allow for multiple independent setup and termination
implementations like this (for style (b)):
init: global f *old_callback_ref = CRYPTO_set_lock_callback(my_lock_func);
... // do thy thing, lib/app
exit: // restore original: CRYPTO_set_lock_callback(old_callback_ref);
and the only thing that needs to be changed for style (b) is the return
type of CRYPTO_set_lock_callback and friends (i.e. the dynlocks):
void CRYPTO_set_locking_callback(void (*locking_function)(int mode,
int n, const char *file, int line));
--> e.g.
typedef void CRYPTO_userdef_locking_function(int mode,
int n, const char *file, int line);
CRYPTO_userdef_locking_function *
CRYPTO_set_locking_callback(CRYPTO_userdef_locking_function *new);
which is at least compile-time backwards 'compatible' as current code
expects a 'void' return type for this API.
So - yes, you probably do need to set the callbacks by default now, and
you
Nope. Doesn't solve anything. (Maybe 'solves' -- on /some/ platforms --
'weird issues' happening to those, em, programmers who don't check sample
code or read man pages and forget about those locks altogether, but that's
a whole 'nother subject matter.)
My 2 cents, donated to the cause.
--
Met vriendelijke groeten / Best regards,
Ger Hobbelt
--------------------------------------------------
web: http://www.hobbelt.com/
http://www.hebbut.net/
mail: g...@hobbelt.com
mobile: +31-6-11 120 978
--------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
