Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Tue, 15 Apr 2008 10:37:22 +0100
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Subject: Re: veto on addition of ssl, evp code
Message-ID: <20080415093722.GA4469@redhat.com>
Mail-Followup-To: dev@apr.apache.org
References: <20080414204254.GA16014@redhat.com> <4803CFFA.1030400@sharp.fm>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4803CFFA.1030400@sharp.fm>
User-Agent: Mutt/1.5.17 (2007-11-01)
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor,
 Berkshire, SL4 1TE, United Kingdom.
  Registered in UK and Wales under Company Registration No. 03798903
  Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
 Matt Parson (USA), Charlie Peters (USA)

On Mon, Apr 14, 2008 at 11:43:22PM +0200, Graham Leggett wrote:
> Joe Orton wrote:
>> h) the undocumented/unspecified API (e.g. in formats of cert/key files, 
>> naming of ciphers) is another leaky abstraction requiring the caller to 
>> know it using OpenSSL underneath; and hence may as well code to OpenSSL 
>> directly
...
> If you can suggest how the interface might be improved, that will help.

Document the API constraints/guarantees on cipher/digest naming and 
cert/key file formats in such a way that a consumer of this API can use 
it without needing to know what SSL toolkit is used underneath.

>> j) it has unnecessary dependencies on SSL_* interfaces in code purporting 
>> to do purely crypto
>
> If they were unnecessary, they wouldn't be there. OpenSSL does not provide 
> getters to extract the information needed by the evp code,

This is still wrong; it is simple to manipulate PEM/DER files using the 
PEM/ASN.1 interfaces and without an SSL_CTX.

>> k) it makes use of interfaces from unreleased versions of OpenSSL (which 
>> may or may not change before release; who knows) - for one of the two 
>> major modes of operation, no less.
>
> Quite correct, you obviously read the documentation included that explains 
> this and why it is classed as "experimental".

This is an arbitrary distinction; once the code hits APR 1.x it is 
subject to the same stability constraints as the rest of the tree. 
Basing such code around an API which only exists in the OpenSSL CVS tree 
is the very definition of premature.

>> l) again, no demonstration that non-OpenSSL-based implementations are even 
>> possible, if an abstraction is the intent.
>
> http://msdn2.microsoft.com/en-us/library/aa380252(VS.85).aspx#csp_data_encryption_functions
>
> http://www.gnu.org/software/gnutls/comparison.html

URLs != demonstration.

...
> A far better solution would be to contribute towards the improvement of 
> this code, which would contribute far more to the usefulness of the project 
> as a whole.

My whole issue is that the EVP code as implemented does not add value to 
this project, and I am yet to see any demonstration that it *can* do so 
in a useful way.  I would much rather see people code against OpenSSL 
EVP directly than use this API.

I'll revert the code, anyway.

joe