Mark Phalan wrote: > > 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.
It can set them before it performs any OpenSSL operations. How is that not safe from races? > > 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? 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 > missing? 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. > > 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. If that's what you want, it's trivial to implement. Simply set callbacks that are safe for the OS' threading model before you call any OpenSSL functions. > 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. > > 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. What is the race exactly? If they're already set, setting them again to precisely the same callbacks is harmless. And if the problem is an application setting them to different callbacks, OpenSSL can't help you -- if an application changes the callbacks from the default to unsafe callbacks, you're still hosed. Existing code that uses OpenSSL will still change those callbacks from the defaults. New applications that don't use OpenSSL at all won't be affected by the change. New libraries could just as easily be coded to always set known safe callbacks. 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 suggested change. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
