"
The right way to do it is have the app set it up at init time, either
through calling the OpenSSL functions directly or through a module/lib's
'init/setup' API if that's the one 'responsible' for OpenSSL activity in
your application.
Just in case some lib developer takes matters in his own hands a bit too
much, a 'only first invocation matters' style of setup might be used for
these and other bits of OpenSSL setup.
"
Sure - it works if you have a simple application, main -> OpenSSL
even main ->lib doing SSL -> OpenSSL still works.
What's giving us grief (and I suspect the person who first raised this
grief) is:
main -> lib that needs SSL to do client server comms -> OpenSSL
-> Another lib that does client server comms. ->OpenSSL
-> Another lib that does crypto ->OpenSSL
All the libraries of the big fat composite application expect to be able to
access OpenSSL's function, all were created independently - the top level
app doesn't do SSL or crypto. at all - it just uses libraries that need to
do SSL or crypto to function.
Yes, it's ugly - alas it's also what happens as time goes by and functions
that were regarded as standalone applications are now library functions -
you only have to look at any of the Unix desktops to see the sort of chaos
that results.
So - even if you don't want to change the defaults - at least add an
option to allow OpenSSL to be built with the system thread model by default
so all those modern (but oh so ugly) apps can still run safely.
Pete
From: Ger Hobbelt <g...@hobbelt.com>
To: openssl-dev@openssl.org
Date: 03/29/2010 11:47 AM
Subject: Re: libcrypto safe for library use?
Sent by: owner-openssl-...@openssl.org
Hrgh. No, you don't init or terminate anything when you're already trying
to execute it from several threads; such init and termination should be
done before and after that.
When a lib (instead of the app itself) is using OpenSSL on its own and that
lib requires a certain approach it is probably coded to set it up. With an
OpenSSL API augmented a la style (a) it can do this safely, i.e.:
init:
if (get_callbacks() != NULL)
{ // flag this situation for termination time and leave those callbacks
the hell alone
}
When the app is using several such libraries and/or doing OpenSSL work of
its own, it should call the OpenSSL init and shutdown/termination APIs
itself to ensure it is set up during the entire lifetime of the app, no way
around that.
What OpenSSL /could/ do is provide a few bits and pieces so that
libraries/modules who think they should be responsible for setting up and
shutting down OpenSSL themselves can check whether someone has done so
already beforehand and change their own actions accordingly; preferably by
leaving the setup alone. Indeed, wrong words by me 'push and pop'; it ain't
a stack.
The 'was OpenSSL set up already? And in a way we expect/require?' check has
to be performed in such [third party?] modules/libraries, at least in
modules/libs who would attempt to init/shutdown OpenSSL on their own.
What OpenSSL init/shutdown code /could/ do to help is maybe 'count' the
number of init and shutdown invocations and only really act on the first
one.
And setting up the callbacks counts as individual pieces of init code, so
they might be 'counted' individually (lock, dynlock, threadid).
That would fix this scenario:
On Mon, Mar 29, 2010 at 2:02 AM, Peter Waltenberg <pwal...@au1.ibm.com>
wrote:
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 ?.
Definitely not.
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.
When the case is init from multiple threads simultaneously, then the memory
callback setup isn't 'safe' for that kind of thing either (none would).
It's just that that particular init is almost never invoked by any 'users'
as malloc/free is a /very/ common answer there. pthreads or what have you
aren't so common so the locking callbacks are a different matter IMO.
The right way to do it is have the app set it up at init time, either
through calling the OpenSSL functions directly or through a module/lib's
'init/setup' API if that's the one 'responsible' for OpenSSL activity in
your application.
Just in case some lib developer takes matters in his own hands a bit too
much, a 'only first invocation matters' style of setup might be used for
these and other bits of OpenSSL setup.
Aw shucks, what am I blathering...
I just checked: ./crypto/cryptlib.c already offers everything you need,
style (a):
void (*CRYPTO_get_locking_callback(void))(int mode,int type,const char
*file, int line) { return(locking_callback); }
int (*CRYPTO_get_add_lock_callback(void))(int *num,int mount,int
type, const char *file,int line)
...
Well, the 'only first come is served' idea isn't in there, but that's not
needed as long as library (instead of application) developers make sure to
check that CRYPTO_get_locking_callback() API before they get all active
about it themselves :-)
It's just that it's not in the man pages on the web site yet, it seems. A
documentation patch perhaps?
--
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
