apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: future of ssl code
Date Wed, 28 Mar 2007 11:48:19 GMT
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.
- 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

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

joe

Mime
View raw message