I'm hitting the deadlock problem that was fixed with http://cvs.openssl.org/chngview?cn=22568 (PR: 2813) Since this fix has not yet been incorporated into enterprise distributions of Linux, I'd like to work around the problem in my application code. I attempted to trace back libcrypto callers of X509_PUBKEY_get() and correlated back to what functions my application is calling. It looks like calls to SSL_new() (with the same SSL context) and also calls to SSL_connect() can cause two threads to be in X509_PUBKEY_get() at the same time. I am thinking of protecting my application's calls to these two functions with a mutex. This will negatively impact performance, of course, since SSL_connect() can block on the network and take quite a while.
I set up tracing via CRYPTO_set_locking_callback() and printed out all the locations that lock CRYPTO_LOCK_EVP_PKEY to get a good sense of what library functions hit this code. The only function call I'm using that will be expensive to mutex-protect is SSL_connect(). Is there a better way of working around this locking bug? Can I change my code such that SSL_connect() no longer calls X509_PUBKEY_get()? Or, can I somehow ensure it's guaranteed to call it with a non-null EVP_PKEY already contained in the X509_PUBKEY? -Eric ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
