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