Mark Phalan wrote: > 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.
If we're talking about existing code, they *must* already set callbacks, otherwise they're hopelessly broken. Since the setting of callbacks will unsafely override the set defaults, the suggested fix (to default to callbacks suitable for the platform's default threading model) actually will *not* fix this case. If this is the case we care about, why implement a fix that won't fix this case? The purported advantage of this fix is that it solves the "horse has already left the stable" case where we aren't willing to change the libraries that call OpenSSL. But it doesn't fix that case. The only way to fix that case that I can think of is for OpenSSL to start out using callbacks that are safe for the platform's default threading API and to ignore, but report success, on all attempts to change the locking callbacks. That may actually be the right behavior for the existing API. (And, of course, OpenSSL would implement a newer, better API that new applications and libraries should use that would include reference counting and being informed of the threading model in use.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
