Hi,
On Tue, 9 Nov 1999, Dr Stephen Henson wrote:
> Yes horrible isn't it?
>
> I've also noticed wildly inconsistent behaviour. When you call something
> like XXX_get_YYY() you might get something which will last only as long
> as the parent and it shouldn't be freed at all or something which will
> persist by virtue of the upped reference count.
sure is horrible ... I played around with this quite a bit yesterday and
the further in I looked the weirder it got. I'd ask why it is this way but
I'm not sure I want to know. :-)
> Also the way reference counts are upped is not friendly. I suppose we
> should have functions like XXXX_up_reference_count(x); for use at an
> application level rather than the current stuff which messes round with
> structure internals.
>
> I'm currently looking into rewriting the verify code. I'm hoping to
> retain compatability with the old behavior except where it does things
> that are really silly. More consistency with the reference counts is
> certainly one issue...
>
> However if it works the way I hope it will then it will support things
> like proper chain verify and certificate trust settings so hopefully no
> one would *want* to do things the old way.
I suppose the problem is that the more code that is built on top of (and
around the skirting of) the existing code - the more there is that will
break if the underlying machinery is fixed up. Adding code that *does*
work logically will be (almost by definition) inconsistent with the
existing API.
I find reference counts extremely useful, but they do more harm than good
when implemented inconsistently. If I have an X509 object, and a call to
"add it to something" returns successfully, I expect that I can hang on to
my reference for as long or short a period of time as I choose before
freeing it and things will "just work". In my case I wanted to maintain my
pointers to ssl, bio_ssl, bio_read, and bio_write and free them all when I
was done with them (not at the same time I might add). One look at the
reference counts and I knew it was not going to be that straightforward.
The most obvious case is that by setting the read and write BIOs on an
SSL, one should be able to free the BIOs afterward and the SSL will still
have references to them. That is not the case - freeing the BIOs causes
the SSL to go bang (ssl/ssl_lib.c:SSL_set_bio). I also tracked down that
weirdness about connecting a BIO_SSL with an SSL, namely it only grabs a
reference to the SSL's read bio (ssl/bio_ssl.c:ssl_ctrl with
BIO_C_SET_SSL). It's described in a comment in crypto/bio/bio.h about line
415. I can't understand why it's done this way and I know if I carelessly
wade in there trying to change it I will unleash the dominos. The fact
that this jumps around between ssl/ and crypto/bio so much is enough of a
deterrent in itself ...
Cheers,
Geoff
----------------------------------------------------------------------
Geoff Thorpe Email: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europe http://www.int.c2.net
----------------------------------------------------------------------
May I just take this opportunity to say that of all the people I have
EVER emailed, you are definitely one of them.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
