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 [email protected] Automated List Manager [email protected]
