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:05:34 GMT
On Thu, November 22, 2007 5:30 pm, Joe Orton wrote:

> If I have to know whether apr-util is built against OpenSSL to be able
> to use this code, it's completely useless.

It is the same pattern used by mod_ssl, and the existing apr_ssl code, so
if this is useless, then it is part of a wider problem.

The EVP interface as it stands does not attempt to address every possible
encryption issue, if it did, the code would never see the light of day.
Instead it represents a base on which an EVP interface can be built.

I could not find an OpenSSL function that would provide a canonical list
of supported ciphers (that is not to say such a funtion definitely does
not exist).

> I can just code directly
> against the OpenSSL EVP interface and cut out the unnecessary overhead
> of the layer in between.

Assuming OpenSSL is available on your platform, which in the case of
Windows, by looking at the existing code, not likely.

Remember that the point of APR is to try and present a standard interface
to end users, where that standard interface hides system specific custom
implementations like CryptoApi or OpenSSL. APR cannot claim to offer every
feature of every library out there (although is it good to try).


View raw message