Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (herse.apache.org: domain of david@jetnet.co.uk designates
 80.87.128.128 as permitted sender)
Message-ID: <460A80DB.3040909@jetnet.co.uk>
Date: Wed, 28 Mar 2007 15:51:07 +0100
From: David Reid <david@jetnet.co.uk>
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
CC: dev@apr.apache.org
Subject: Re: future of ssl code
References: <460A461E.4050308@jetnet.co.uk> <460A59CC.4020600@rowe-clan.net>
In-Reply-To: <460A59CC.4020600@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> David Reid wrote:
>> A while back there was a comment on this list that the ssl code should
>> be "ripped out" before the next release. There was no additional
>> information as to why, but that's OK.
> 
> Actually, I don't know that it is OK.
> 
> 1.2.9 on the current-stable branch should be released shortly.  Independent
> of the 1.3 changes for SSL.
> 
> Does SSL block any other change in 1.3?

Not as far as I'm aware.

> 
>> Maybe it should be removed into a seperate module along the same lines
>> as apr-iconv? Additionally we should look at what really needs to go
>> into it. There are a few bits of code that I'd like to think about
>> moving into a library with apr's platform independance, but the bloat
>> that is apr-util no longer seems like the ideal landing site.
> 
> In fairness, the bloat which is apr-util is agreeably just-bloat.  Don't
> worry about it, there is a much greater urgency to remove 4 of 6 db libs
> which an application won't consume, or ldap for a non-ldap application.
> And ssl, if ssl is not used by an application.
> 
> It's a bigger problem than the openssl bindings.

I realise that, but several people have now mentioned other aspects of
openssl that they'd like to see supported. Other libs have been
mentioned as well. I think all the things that people have mentioned are
valid and would be useful additions, but I'm not sure I really want to
simply lump them all into apr-util. Having this as a standalone seperate
module probably does make more sense in the long term as I can envision
having both an apr-ssl and apr-crypto library. Moving these to a
seperate repo within apr would seem like the best plan as that way they
can be developed on their own timeline, with features coming and going
as required for the development process.

> 
>> So, thoughts? Comments? Suggestions?
>>
>> FWIW, this will have ramifications for some other code that I plan on
>> working on soon(ish).
> 
> A big comment.  APR and APR-util current include non-FIPS implementations
> of FIPS-140 specified algorithms.  OpenSSL built with FIPS enabled has
> proper implementations.  So please don't begin yanking openssl.
> 
> In fact I need to toggle off those apr-implementations, and stub in
> openssl's implementations in the presence of some --enable-fips flag.

I don't see how this has direct implications on what happens with the
ssl code, but I'm willing for you to correct my misunderstaning :-)

> 
> Apache+APR+OpenSSL won't 'become FIPS certified' (in fact, only a small
> core of OpenSSL is fips validated).  But as things stand, it violates
> the FIPS standard and security policy document.  I hope to change that.
> 
> So we can all agree that apr-util is bloated, but please leave things
> as-is for 1.3?

Given Joe's stance (which I'm taking as a veto) I think removing it and
starting a seperate "module" within apr's repo would make the most sense
and should remove the veto from 1.3 - making everyone happy.

AFAIU we don't need anything special for the move, but the PMC will
likely need to have a vote or sacrifice a goat I guess?