Normally application create a single SSL_CTX structure before starting
any threads and muliple SSL structure from that SSL_CTX so that problem
doesn't arise.
In my app, multiple threads call into the *_client_method structures because
they don't know ahead of time which transport to use.
All (most?) similar cases clear the 'init' flag *after* having set up
the data structures appropriately, e.g. see ssl/s3_meth.c.
Yes, SSLv3_client_method is the only one I saw which had init set in the
wrong place. I may have missed some.
No locking should be needed because the assignments
However, the assignments are not atomic. The following unprotected
operation:
if (init)
{
memcpy((char *)SSLv3_server_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_server_data.ssl_accept=ssl3_accept;
I wrote that the next snapshots should solve the problem. Functions
SSLv23_client_method(), SSLv23_server_method(),
SSLv2_client_method(),SSLv2_server_method(),
SSLv3_client_method(),SSLv3_server_method(),
TLSv1_client_method(),
You are absolutely right, of course. I got similar constructs right
in the past, but I guess this time I was too busy with various other
things to really think about what I was writing ...
The next snapshot should really fix the problem.
I looked at the changes in CVS and everything seems
Looking at it tho', there's still a couple of problems. Here's one
example of the first one,
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
memcpy((char *)SSLv23_client_data,
(char *)sslv23_base_method(),sizeof(SSL_METHOD));
