apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: veto on addition of ssl, evp code
Date Mon, 14 Apr 2008 21:43:22 GMT
Joe Orton wrote:

> Per the other thread, the review for this has mostly been ignored. I 
> have no wish to waste time banging my head against a wall, so I am:

You raised questions after the code was committed in November 2007, and 
then didn't bother to follow up when those questions were answered. Six 
months of silence followed with a veto does not fit my definition of 
"banging your head against a wall".

To answer the issues yet again, in the hope that this will result in 
some kind of resolution:

> and I am also -1 on the addition of the EVP code, r597209 et al, on the 
> basis that:
> 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

The reality behind the underlying toolkits is that neither OpenSSL, nor 
(not my knowledge when I looked) Microsoft Crypto API provide lists of 
what parameters are supported, so you are expecting APR to expose 
functionality that doesn't exist.

If such functionality can be obtained from the underlying toolkit, that 
can be achieved through the addition of an extra function at a future 
date. There is no need to change the current interface for that. This 
does not support a veto IMO.

If you can suggest how the interface might be improved, that will help.

> i) apr_evp_factory_create represents unnecessarily bad API design; 
> requiring a single entry point for a dual-purpose function which ignores 
> half its arguments depending on a "purpose" switch.

It works like the SSL side of the code works, and you're right, it 
should probably be changed.

> 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, and 
so some hoops have to be jumped through to get at the information. To 
fix this, we must fix OpenSSL.

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

We can anticipate the functionality today, or we can wait until APR3 to 
break our API to support it when OpenSSL is ready.

> l) again, no demonstration that non-OpenSSL-based implementations are 
> even possible, if an abstraction is the intent.



> I hope that is considered sufficient technical justification for the 
> vetos.  Note that most of the points above are not new and have been 
> posted on this list six or twelve months back.
> I know that the veto is a horrible uncivilised blunt instrument.  I am 
> happy to see this code branched off somewhere where those interested in 
> developing it further can do so.
> I am also happy to do the grunt work of reversion if the authors are 
> still unwilling to resolve these issues and don't want to (or don't have 
> time to) do that themselves.

I have just spent the last three weeks full time devoted to bringing to 
a close the session functionality for httpd, after developing it part 
time for over a year. This has overrun and I need to do some paid work 
which is now overdue so that the bills get paid, which means that I do 
not have time this week to drop everything and change evp just for you.

If you revert this, you break mod_session_crypto, which in turn severely 
limits the usefulness of mod_session_cookie, which in turns limits the 
usefulness of mod_auth_form, which is turn limits the usefulness of 
httpd's powerful AAA mechanism that has been sadly limited to Basic and 
Digest auth only for the last ten years.

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.


View raw message