On 03/29/10 07:15 AM, Peter Waltenberg wrote:
" 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.
You've summarized my issue well :) This becomes a particular problem when multiple threads are dlopen'ing plugins which link against OpenSSL or libraries which do so. The initialization routines of the plugins now have two choices: 1) Race to set the locking callbacks or 2) Don't set the callbacks. Neither option is very desirable.
...
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.
+1 -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
