On 03/26/10 10:47 PM, David Schwartz wrote:
Mark Phalan wrote:
Unfortunately that's not really practical. To take an example I'm
familiar with - libgss. libgss can end up calling into OpenSSL in the
following way:
libgss -> kerberos -> pkinit plugin -> openssl
It's simply not practical to change libkrb5 and libgss and all
applications using those libraries.
In this case, I presume 'pkinit' only supports one threading model (or one
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
from races.
Well on Solaris it's most likely going to be using either POSIX threads
or Solaris threads which are interoperable and can be used in the same
application. If an application wants to do something unusual it can set
the callbacks. I'm not suggesting that applications should lose the
power to set locking callbacks.
Having default callbacks will simply mean that applications which don't
use OpenSSL or don't set callbacks will be more likely to work.
Then set default callbacks in your code that calls OpenSSL. OpenSSL can't do
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?
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 missing?
I agree. Your library should impose a requirement on any application
that
uses it that it inform you of the threading model it's using so that
you can
use appropriate locking as well. Then you can set the OpenSSL locking
callbacks (just pass them through) and there's no chance of a race or
problem.
See above. That's simply not practical (the horse has left the stable).
If the horse has left the stable and the code supports more than one
threading model, then the problem is provable insolvable. There is simply no
way for OpenSSL to know what kind of locks are adequate. If your code
supports only one threading model, then you can tell OpenSSL this by setting
the callbacks.
What I could do is say that when delivered as part of OpenSolaris
OpenSSL assumes the OS's threading model. If an application wants to
change that they the application should set its own callbacks.
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.
Multi-threading issues, as a general rule, have to be resolved at
application level. It cannot be done by libraries because they don't have
sufficient knowledge.
And this is precisely the problem. For the case where an application
isn't using
...
Since libldap_r knows what threading model the application is using, it can
do this. OpenSSL doesn't know, so it can't do this.
It can do this but only by potentially introducing a race.
Thanks,
-M
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
