On 03/30/10 09:16 PM, David Schwartz wrote:
Mark Phalan wrote:
In this case, I presume 'pkinit' only supports one threading model
set of compatible threading models). So it can set the callbacks.
It can set the callbacks but it can't set them in a way which is safe
It can set them before it performs any OpenSSL operations. How is that not
safe from races?
I think Darryl answered that.
Then set default callbacks in your code that calls OpenSSL. OpenSSL
it, because it has no idea what threading models your code uses.
Perhaps I don't understand exactly what you mean by "threading model".
Are you referring to 1:1, n:1 etc?
That's part of it. It's also what threading library you are using.
I think it would be reasonable for OpenSSL as delivered with an OS to
use the native threading model of the OS. Is there something I'm
If you only support one threading model, there's no problem. Just set
callbacks that are safe for that threading model before you use OpenSSL.
(Speaking as someone who cares mostly about OpenSolaris)
I think the special-case here is when someone decides not to use the OS
threading model. In that case the application can simple set the
callbacks replacing the ones automatically set.
Just to be totally clear. All I'd like to see is a compile-time option
(it can be disabled by default) to set a default set of locking
callbacks native to the OS it's compiling on. I'm not suggesting that
the ability to set locking callbacks be removed.
If you are able to craft a default set of locking callbacks that are safe
for your application, then do so and set them. I don't see what assistance
you need from OpenSSL. If that is your case, your solution is trivial -- set
those callbacks. If you know they're safe, set them.
I see no problem with applications. The problem only arises with
libraries linking against OpenSSL, especially when they are dlopen'ed
and the application isn't even aware of that that is happening and the
application isn't already using OpenSSL.
To use an example a colleague pointed out to me recently:
Application calls getpwnam()
getpwnam -> nsswitch -> dlopen nsswitch_ldap ->
ldap uses SSL -> libssl
ldap uses SASL ->
libsasl -> GSS-API
libgss -> Kerberos
dlopen mech_krb -> dlopen pkinit
pkinit -> OpenSSL libcrypto
There is only a race if some application either reverts to no callbacks or
sets unsafe callbacks. Both of those operations will still be fatal with the
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.
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager majord...@openssl.org