On Wed, Nov 17, 1999 at 12:40:55PM +0000, Geoff Thorpe wrote:
>>> It seems that
>>> everything works if you make the calls the way the authors had intended
>>> rather than making the calls the way the authors made available.
>> How can you tell what is the "intended" way? For SSL_get_session, the
>> code consistently assumes that no free-ing is necessary (cf. apps/s_*.c),
>> althoughly surely it would have made sense to demand it.
> Intended way = (i) an SSL_SESSION pointer is not supposed to outlive the
> SSL pointer from which it came.
Ok, yes; I thought you meant it the other way around.
> (ii) an SSL poiner is only supposed to
> have one reference to it and programs that wish to have multiple
> references (whether in the same thread or otherwise) had best work out
> their own way of doing it using one reference.
>
> Available way = reference counts, gets, sets, adds, and frees.
>
> Available way = reference counts, gets, sets, adds, and frees. If it looks
> like reference counting and it talks like reference counting then callers
> will reasonably hope it *is* reference counting.
I agree, however it's not as if the library had consistent behaviour
with just this one exception ... (and with the examples in
e.g. s_client.c it's very easy to find out how one is supposed to use
this -- at least compared with, say, finding out how the "copy"
parameter for session cache callbacks works :-)
Using new function names that state explicitly whether the caller
gets their own reference or not is what we should do, not break
exisiting code.
[...]
>> The trouble is that 0.9.4 has various bugs which should be fixed for
>> all applications before upgrading to the new library version becomes
>> too difficult.
> fair enough. The only thing I'd like to add though is that the behaviour
> *IS* changing inside 0.9.5-dev and I noted an example on openssl-dev a
> while back about it and ended up giving up on that piece of the API and
> cutting down below it myself. Namely the SSL_CTX_load_verify_locations
> behaviour changed in a way that broke my code *and* (as it turns out)
> broke ssltest (if you specify a -CAfile). The only reason it didn't break
> s_client and s_server was that its calls were being back-doored by;
>
> [s_server.c:643]
> if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
> (!SSL_CTX_set_default_verify_paths(ctx)))
>
> and because set_default_verify_paths succeeds, the fact that passing a
> CAfile into load_verify_locations fails is ignored.
This behaviour change probably should not have happened -- your
message about it is still in my queue; I haven't yet found time to
track down exactly what is happening and why, and to determine how
things would make more sense.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
