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 16:19:17 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.
> 
> Some API problems:
> - error handling is broken. lots of places return "-1" as an 
> apr_status_t.

Corrected.

> - apr_ssl_socket_raw_error() breaks the abstraction and exposes the ABI
> of the SSL implementation

Part of a larger issue with the error handling.

> - prototypes lack parameter names in many cases, hard to read

Docs all in place and give explanations right above the prototypes.

> - 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?

To allow for different implementations that need to not use the
underlying sockets (assuming such things exist).

> - 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.

Fixed.

> - no cert verification if used for a client => SSL without 
> the "security"; this needs API help to pass in the server name

Care to explain a bit more?

> 
> 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

True. Have to look at how we fix this.

> - lots of argument validation (APR_EINVAL returns) which is non-standard 
> for APR

I don't see why this is a huge issue.

> - does nothing really to support non-blocking writes as API claims

Again, care to explain a bit more?

david

Mime
View raw message