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
