apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Reid <da...@jetnet.co.uk>
Subject Re: future of ssl code
Date Wed, 28 Mar 2007 14:44:24 GMT
Joe Orton wrote:
> On Wed, Mar 28, 2007 at 11:40:30AM +0100, David Reid wrote:
>> A while back there was a comment on this list that the ssl code should
>> be "ripped out" before the next release. There was no additional
>> information as to why, but that's OK.
> 
> Are you saying it *is* in a state ready for a 1.3 release, with the 
> API/ABI constraints that entails?  It went in as a (quote) "first dump", 
> and has seen little improvement since then.

I wasn't commenting one way or the other.

> 
> Some API problems:
> - error handling is broken. lots of places return "-1" as an 
> apr_status_t.
> - apr_ssl_socket_raw_error() breaks the abstraction and exposes the ABI
> of the SSL implementation
> - prototypes lack parameter names in many cases, hard to read
> - attempting to wrap every apr_socket_* function seems futile; why not 
> just expose the apr_socket_t * pointer and let users deal with it directly?
> - having a "factory" keyed by "private key, cert, digest type" is 
> obscure. digest type of what?  Requiring "no pkey/cert == server" is 
> also weird:  clients can have private keys and certs too.
> - no cert verification if used for a client => SSL without 
> the "security"; this needs API help to pass in the server name

OK, I'll work through these. It was the lack of any form of feedback and
the blanket "it should be yanked" that had me stumped. lets face it,
there hasn't been much discussion of the code.

> Some implementation problems:
> - is the OpenSSL code intended to be Unix-specific?  It assumes 
> apr_os_sock_t is an fd I guess, by passing it to SSL_set_fd
> - lots of argument validation (APR_EINVAL returns) which is non-standard 
> for APR
> - does nothing really to support non-blocking writes as API claims

OK, good points and something I can at least work towards.

I'm more than willing to try and fix these, but when faced with just
negative comments it was hard to know what people felt needed fixed.

Thanks for clarifying Joe.

> 
> joe
> 
> !DSPAM:16,460a56311814816939239!
> 
> 


Mime
View raw message