Geoff Thorpe <[EMAIL PROTECTED]>:
>> The idea is that you hand those BIOs over to the SSL library, you
>> usually don't keep pointers of your own. SSL_free(ssl) will call
>> BIO_free for each of them, but just once if bio_read == bio_write, so
>> usually everything works as intended. Obviously this is not the
>> cleanest interface conceivable ...
> Well as I mentioned repeatedly on the SSL_SESSION discussion a while back,
> "the idea is that ..." seems to be common justification for deliberate and
> lazy inconsistency, both from the point of view of the library design, and
> from the point of view of library-usage.
No, there are also inconsistencies that cannot be justified this way :-)
(SSL_CTX_set_tmp_dh does not increase a reference count or copy the
structure, while SSL_CTX_set_tmp_rsa does. There is an explanation
for this, but I would not call it a "justification".)
> In this case I think the
> programmer(s) just wanted to "throw the BIOs into the SSL and forget about
> them" ... ie. why free your reference when you can just pass it over to
> another structure and forget about your references? Whilst this "works" it
> makes a mockery of the so-called "reference counting mechanism" and leaves
> programmers constantly in a quandry as how to correctly manage references
> - and occasionally how to avoid race-conditions too!
Which is why, one day, we should provide variants of all those "set"s
and "get"s that somehow encode in there names whether reference counts
are increased or not.
[...]
> "handing over" references and such cutting of corners leads to these
> inflexibilities in the way these objects/structures can be used.
Agreed.
>> [...] If you
>> keep only the bio_ssl pointer, BIO_free_all will free everything
>> (bio_read will be freed twice because it's also at the next_bio
>> pointer, so its reference count goes down to zero).
> But I don't want to "keep only the bio_ssl pointer" ... for one thing,
> once that handshake is complete I want to examine the session negotiated,
> grab the peer certificate (both of which reveal further reference counting
> anomalies but that's another soap-box), and possibly other SSL things that
> have nothing to do with the BIO which is simply an IO device.
If you want to do those SSL things, then the easiest thing is not to
use a bio_ssl in the first place. Many programs work directly with
SSL pointers without adding the extra BIO layer; probably this is why
the reference-counting problems inherent in bio_ssl's don't seem to
disturb too many people. (Or, they avoid bio_ssl's *because* they
look strange.) Similarly, using memory BIOs like ssl_test.s does
always looked like an ugly kludge to me, presumably because it is --
thus usually the read and write BIOs are the same and the reference
counting problems in this area are not visible to the library user.
[...]
>> That's why the comment in bio.h says "WARNING WARNING ... make sure
>> you are doing a BIO_free_all()" since SSLeay 0.9.0b. BIO_free_all
>> follows the next_bio chain, BIO_free does not; I'm not sure if
>> BIO_free has any use at all except when you are sure that that
>> next_bio == NULL in which case both functions do the same anyway.
> Hardly bodes well when one has to sift through the .h file to discover API
> design comments that themselves admit to being a tad obscure and, even
> after finding and reading, leaves us in some doubt as to how things work
> and what the point is.
Finding out how things work is usually possible given that the source
is available; I'm not always sure what the point is though.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
