httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Encoding code in APR
Date Fri, 07 Jul 2000 14:52:36 GMT

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

I am not mixing arguments, your not paying attention.  :-)

The MD5 algorithm is only portable if everybody implements it as
stock.  Not every platform does.  This was proven on FreeBSD, where we
couldn't GET a stock version of MD5 so that the same passwords could be
used on Unix and Windows, or even two Unix boxes that weren't running the
same version of FreeBSD

> *) 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)

The problem is Apache versus APR.  If MD5 isn't in APR, then we don't have
our own implementation unless we are Apache.  It's that simple.

> *) MD5 and SHA1 are *hash* algorithms. not encodings. base64 is an encoding.

Read the code please.  As I said before ALL of the code refers to
encoding data.  That sure makes it sound to me like they can be used as
encoding algorithms.  Whether that was their purpose or not is
irrelevant.  They can be used to encode data.

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

No.  I am trying to remove apr/lib, because it is a horrible mess of
unrelated functions.  I would like for it to be easy to find functions in
APR, and currently it isn't inside of lib.  Whenever I have to give a
presentation about APR, I have a section in my talk about "Functions moved
from Apache 1.3 to APR".  That is horrible.  I am moving things out of lib
sometime next week, and making new directories for them.

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

Fine.  I'm not going to argue about this anymore.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message