apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: future of ssl code
Date Wed, 28 Mar 2007 15:09:43 GMT
David Reid wrote:
> William A. Rowe, Jr. wrote:
>>
>> Does SSL block any other change in 1.3?
> 
> Not as far as I'm aware.

One I can think of - the threadpool API, but I'm willing to wait for
a richer feature set before calling 1.3 baked.

I'm pretty sure httpd would like to pick up 1.3.x by the time they are
ready to ship httpd-2.4, but that's a little ways off yet and still.

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

I really don't want the entire kitchen sink.  If we can keep this to the
essential nuts and bolts of a TLS conversation, and extracting information
about the client and server credentials, then we won't end up with an
extension of openssl that CAN'T be supported with cryptocme, gnutls or
other equally valid ssl/tls implementations.

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

We both need to consume openssl, for different elements.  In fact, I'm
thinking of refactoring all the pieces that are subject to FIPS-140
explicit implementations (which will just be stubbed out to openssl),
and these include every algorithm we have that is part of the openssl
project's fips_canister, such as sha1 hashes.

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

I definately don't want to see this handled piecemeal.  Please leave it in
place, and Joe please reconsider your veto.

The right way to handle it is to agree to agree on exactly how we will
change the ldap/dbm/dbd/xml/xlate/ssl library bindings to be dynamic
or modular.

Until we agree on that, I DON'T want to special-case ssl :(  It's wasted
effort.  Let's focus on addressing the real issues folks have identified
in the apr_ssl_* implementation?

Bill


Mime
View raw message