> 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));
> SSLv23_client_data.ssl_conn
> 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 se
> 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(),TLSv1_serve
> > 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;
> >
> 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 assignment
> 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. P
