apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Leggett" <minf...@sharp.fm>
Subject Re: svn commit: r597209 - in /apr/apr-util/trunk: CHANGES build/ssl.m4 include/apr_buckets.h include/apr_ssl.h include/private/apr_ssl_openssl_private.h ssl/apr_ssl_openssl.c ssl/apr_ssl_winsock.c
Date Thu, 22 Nov 2007 16:13:18 GMT
On Thu, November 22, 2007 4:56 pm, Joe Orton wrote:

> Ah, I missed the ssl.m4 change.

> The apr_evp_factory_create() interface is just poor API design.  Instead
> of having the "purpose" enum and a single function which ignores half
> the arguments depending on which "purpose" is used, have two separate
> functions.

Again, this was modelled on the existing code, and I wasn't happy with it
either. Will change both the apr_ssl_* and the apr_evp_* factories to be
more specific.

> The "engine" argument seems completely unused and
> undocumented, also.

That's read "not supported yet", it will be shortly. No use someone
deciding to release v1.3.0 and we find the API is stuck till v2.0 for the
want of an extra field.

> All the SSL_CTX seems to be used for is to read PEM-format files, which
> is massive overkill; "man PEM".

Again modelled on existing code. If the apr_ssl routines accept a cert
(like DER), it makes no sense whatsoever if the apr_evp routines don't.

> As with the existing SSL code there is absence of consideration of how
> to handle the OpenSSL error stack and abstracting errors; at least
> clearing it after failure would be the minimal acceptable if there are
> no errors which need to be distinguished in the API.

The OpenSSL docs are very vague on the issue of how openssl errors are
handling in the EVP functions. The docs only mention return codes, however
I plan to check in more detail.


View raw message