Historically I suspect the reason there were no default callbacks is that a
sizeable proportion of OpenSSL users didn't use threading at all, and the
baggage hauling in the thread libraries imposed was significant.
I don't think that's an issue anymore - threading is the common case now.
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).
So - yes, you probably do need to set the callbacks by default now, and you
probably need to make that API a no-op as well. By all means have a compile
time option to restore the old behaviour for the set of users who need the
legacy behaviour - but that's likely a very small set now.
Peter
From: "David Schwartz" <dav...@webmaster.com>
To: <mark.pha...@sun.com>, <openssl-dev@openssl.org>
Date: 27/03/2010 07:57 AM
Subject: RE: libcrypto safe for library use?
Sent by: owner-openssl-...@openssl.org
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. Any
application that uses 'pkinit' must be okay with those callbacks.
> > It can't do that, it has no idea what threading model the application
> > is
> > using. It would have no way to know whether the locks it provided
> > were
> > suitable or sensible.
> 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.
> > 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.
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. Things like signal handlers are process-level
resources. The same is true of what kind of mutexes are needed to protect
structures from concurrent accesses that come into a library from outside
it.
> I should also point out that libraries are setting the callbacks already.
> libldap_r (openldap) for example. I haven't done an extensive survey of
> common opensource libraries but I'm sure openldap isn't alone out there.
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.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
