httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Encoding code in APR
Date Fri, 07 Jul 2000 11:41:48 GMT
On Thu, Jul 06, 2000 at 08:40:39AM -0700, wrote:
> I thought of another reason why the md5/sha1 encoding code needs to be in
> APR.  It may be VERY portable code, but the results aren't portable.  I
> know that makes very little sense.  Think about why we decided to always
> use the Apache MD5 code on all platforms.  We got the code originally from
> FreeBSD, so we know they have the code, we could have used the crypt
> function on FreeBSD.
> If you review the archives, you'll discover that later versions of FreeBSD
> modified their version of crypt to produce different results.  They are a
> bit more secure IIRC, but the results are also just not portable.  This
> means that if we don't put the encoding stuff into APR, and somebody uses
> an MD5 algorithm on a FreeBSD box, that code will not be portable to a
> Windows machine using APR with the lib/util MD5 algorithm.

You're mixing your arguments here.

*) crypt() is non-portable
*) the MD5 hash algorithm is totally portable

The problem that you refer to is trying to use crypt() to do MD5 hashing.
That just doesn't work.

> With this argument and the argument laid out yesterday about not all
> platforms having encoding API's, does anybody still have a problem with
> creating lib/apr/encode, and putting ap_(md5/sha1/base64) there?

*) the above argument doesn't hold
*) not all platforms have these hash algorithms, but that doesn't matter --
   we already said that we will never attempt to rely on the platform's hash
   functions (we have our own, so use it)
*) MD5 and SHA1 are *hash* algorithms. not encodings. base64 is an encoding.

All that said, I have discovered a reason for MD5 to be in APR, and it has
nothing to do with the above :-) ... APR needs to do UUID generation which
is non-portable. Win32 has UuidCreate(), but other platforms need to roll an
algorithm. Part of the UUID is random data. This can be fetched using
something like the "truerand" library (which is already in APR?). But when a
good random number generator isn't present, then a great way to generate
random bytes is to apply the MD5 hash to a block of data. By definition, the
result is random :-) ... in any case, this means that APR itself will have a
dependency upon MD5 hashing. Therefore, it needs to include it.

May as well toss the SHA1 hash in there. The two files would simply go into

I don't see an argument for base64 encoding, though. I would disagree with
moving that into APR.


Greg Stein,

View raw message