"Simon J. Gerraty" <[EMAIL PROTECTED]>:

>> The comment in ssl_lib.c says: [...]

>> This says what was changed, but gives no justification for it.
>> Is there some class of problem which is solved by this change?

Yes.  The code that handled all those data structures (and used the
SSL_CTX's cert if the SSL did not have one) was utterly
incomprehensible and (as usual in such cases), on close look, even
incorrect.  Two concurrently used SSLs created from the same SSL_CTX
with shared certs would treat the shared data structure as private and
write to it, without expecting that the other one could do so as well.

>> Re-ordering everything so that the first call to SSL_new() is after the
>> reading of the private key will complicate things in ugly ways.  And that

> Yay! Sorry for the noise.   The addition of SSL_CTX_set_verify() and
> SSL_CTX_set_cipher_list() mean that I can indeed defer calling
> SSL_new() until I actually need it.
> 
> With a _few_ not too ugly changes I have SSLrsh[d] working with OpenSSL.

And of course if you could not defer calling SSL_new, there'd be the
option to set the private key for the SSL structure, not the SSL_CTX
structure; in case you have to create multiple SSL structures from the
same SSL_CTX, you could read the key once and then set this key for
each SSL.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to