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, 11 Apr 2007 11:25:00 GMT
On Wed, Mar 28, 2007 at 05:19:17PM +0100, David Reid wrote:
> Joe Orton wrote:
> > - prototypes lack parameter names in many cases, hard to read
> 
> Docs all in place and give explanations right above the prototypes.

The right place for paramater names is in the C function declaration, 
not in a doxygen comment.  If you get the function declaration right, 
the doxygen @fn stuff is unnecessary.

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

Question remains: digest type of what?

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

It's a fundamental part of SSL that clients must verify server identity 
in some way.  See e.g. RFC 2818.

> > - lots of argument validation (APR_EINVAL returns) which is non-standard 
> > for APR
> 
> I don't see why this is a huge issue.

It's not huge, but it's an issue.

> > - does nothing really to support non-blocking writes as API claims
> 
> Again, care to explain a bit more?

Well, using the defined API, how do I differentiate a write-which-failed 
from a write-which-blocked?  Partly this is just lack of error 
abstraction.

joe

Mime
View raw message