Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <4498EA6E.7070601@rowe-clan.net>
Date: Wed, 21 Jun 2006 01:42:54 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.4 (X11/20060614)
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: svn commit: r415639 - in /apr/apr-util/trunk: build.conf
 include/apr_ssl.h
 include/private/apr_ssl_openssl_private.h include/private/apr_ssl_private.h
 ssl/ ssl/apr_ssl.c ssl/apr_ssl_openssl.c ssl/apr_ssl_socket.c test/
 test/Makefile.in
 test/testssl.c
References: <20060620134158.B63471A983A@eris.apache.org>
 <20060620140531.GA875@redhat.com>
In-Reply-To: <20060620140531.GA875@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Joe Orton wrote:
> On Tue, Jun 20, 2006 at 01:41:52PM -0000, David Reid wrote:
>> Author: dreid
>> Date: Tue Jun 20 06:41:51 2006
>> New Revision: 415639
>>
>> URL: http://svn.apache.org/viewvc?rev=415639&view=rev
>> Log:
>> First dump of some ssl sockets code. This follows the methodology of the
>> patch, but attempts to break out everything that is specific to OpenSSL
>> into a seperate file. The rationale shouldn't be hard to follow.
>>
>> This does makes things slightly moer complex and adds another layer of
>> indirection, but there shouldn't be much of a hit because of it. Hopefully
>> this will be generic enough that some windows person can add win32 support?
> 
> This looks quite a long way from being ready.  Good intentions 
> notwithstanding (but certainly appreciated) I'd rather see this develop 
> in a branch before hitting the trunk, I don't want to end up with 
> another "apr/random affair".

Well, first win32 support is reasonably trivial and I'll add it in Dublin.
I'll also propose the code to replace 'apr hashing' with OpenSSL hashing,
and some of the other silly wheels we reinvent.  Of course we can fall back
on our own implementations when the user doesn't build against APR.

This actually means, if the user builds in a FIPS mode, that md4 and md5 both
return ENOTIMPL because they go against FIPS policy, while if it isn't against
a FIPS build we can use DES_crypt instead of machine 8-char-silly crypt.  (This
means real htpasswd support on win32, and portable htpasswd crypt if the user
so chooses - hmmm, aught to think of a way to toggle that explicitly.)

But I'm not expecting many would build apr against openssl-fips validated
crypto, until httpd is also ready (which it is, Ben started the work, I finished
it for RSA, now to bring this effort back to the party.)  Don't worry about the
app you have which calls apr_md5 right now breaking in the next release.  (Oh,
but consider using a better hash like sha1 or sha2 family :-)

I'd suggest that if you want to prepare to release a 1.3 without these features,
that we simply branch from prior to David's last commit.  I'm neutral, and would
frankly invest more in this 'current branch' than some offshoot of yesterday's
trunk.  But I don't see a reason to stop progress, either by a prospective RM
"right now" or by committers working on new things.

> - header files need documentation not just function stubs
> - global symbols must use ap[ru] prefix even if they are project-internal
> - no symbols must start with an underscore
> - C++-style comments bad

All good points.