On Fri, Oct 12, 2001, Chris D. Peterson wrote:
> Thus spake Lutz Jaenicke ([EMAIL PROTECTED]):
>
> > I know it has been a long time, but I have just continued to analyze
> > your submission.
> > I have not yet applied your patch. With respect to the SSL_SESSION_free()
> > problem, it would only cure the symptoms of incorrect SSL_SESSION_free()
> > use. It is not just the session list inside the SSL_CTX object; if a session
> > is used by an SSL object we would also find a dangling pointer that we
> > could not catch.
> > The point should not be to cover for incorrect use of SSL_SESSION_free()
> > and "magically" remove the session from the cache list, but to catch
> > this as an error... Unfortunately SSL_SESSION_free() does not return
> > diagnostic information (until now), so no application written with today's
> > API would catch the error message...
>
> I don't claim to understand this code well enough to contradict you.
>
> It would certainly be an improvement to have SSL_SESSION_free() detect
> this error condition and complain loudly when it occurs.
>
> I also agree that an interface change is probably worthwhile to do
> better error reporting and recovery when this occurs.
Actually I think that we could find a quite acceptable solution while
keeping the API on the argument level (so applications not evaluating
return values could stay unchanged) by adding a pointer to the SSL_CTX
object to the SSL_SESSION structure. If a SSL_SESSION object is linked
into an SSL_CTX session cache, we know which SSL_CTX it is. As only
one prev and next pointer are available, we can only have one SSL_CTX
information. If it is NULL, the session is not part of a session cache,
if it is set, we know the SSL_CTX.
I just tried to apply your patch but it failed for both 0.9.7-dev and
0.9.6b. Would you kindly download a 0.9.7 snapshot and adapt your patch
to the snapshot and resubmit it? You can do the extension for the SSL_CTX
object in the SSL_SESSION structure (if you don't do it, I have to include
it myself).
Best regards,
Lutz
PS. Answers via list or to my @openssl.org address. My TU-Cottbus address
is not functional again before Monday, because the campus-firewall switched
to the state of "total email security", all connections with respect to
port 25 for the whole university are blocked (and the administrators are all
out for the weekend...)
They'll probably have something to explain on Monday :-)
> > By now, I have updated the manual pages to reflect this problem and wait
> > for more input with respect to this problem.
This will stay the "fix" for 0.9.6c. The code (and maybe API) change will
only make it into 0.9.7.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~jaenicke/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
