apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/test aprtest.dsp aprtest.dsw aprtest.win Makefile.in sendfile.c testmmap.c client.dsp htdigest.dsp server.dsp test.dsw testarg.dsp testfile.dsp testproc.dsp testsig.dsp testsock.dsp testsuite.dsw testthread.dsp testucs.dsp timetest.dsp
Date Tue, 05 Dec 2000 03:41:24 GMT
On Mon, Dec 04, 2000 at 09:27:38PM -0600, William A. Rowe, Jr. wrote:
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Monday, December 04, 2000 5:52 PM
> > I'm suggesting the following:
> > 
> > 1) MD5 hashing moves to apr-util since it is portable
> > 2) add crypt() covers into APR (APR_HAS_CRYPT and the appropriate -lcrypt
> >    switches if needed for the platform)
> > 3) apr_validate_password() moves to apr-util/src/crypto/. it uses MD5 or
> >    apr_crypt() as appropriate.
> 
> Why are we proliferating this problem, again, and still?

I'm unclear about what you're referring to... Which problem? That crypt()
doesn't exist on some platforms?

> I understand that there are no significant export issues remaining with the
> original crypt() functions,

Correct. crypt() is an implementation of the DES encryption algorithm, which
has been free of export restrictions for a while now; especially after the
recent lifting of most restrictions on open source.

> and they are available under free bsd license,
> correct?

I would presume so, but don't know definitively.

> This is a portability issue in itself, though one that could be
> very reasonably implemented/handled in aprutil.

Euh... nope. crypt() is a function where we want to use the platform
function if possible. crypt() can be configured on some platforms to do MD5
encryption.

If we were to write, say apr_des_encrypt(), then yes: that could go into
apr-util since it is entirely portable.

But my main point was that we use crypt() in a couple areas of our code.
crypt() is non-portable and APR should do some work to make it available to
apps (if/when available; we'd have APR_HAS_CRYPT)

> > apr_validate_password has some platform #ifdefs in there
> > that can easily go away if apr_crypt() existed.
> 
> It should _never_ accept unencrypted anything (which it will under some
> platforms.)  It should iterate through crypt, md5 and sha1, because the
> author of the code may be relying on files from other platforms, and other
> eras.

This is a different problem. For the moment, I'm interested in seeing MD5
functionality and apr_validate_password move into apr-util. Part of that
move is to add APR_HAS_CRYPT into APR itself.

Once that is done: yes, we can munge apr_validate_password further. But I
don't want to see us get distracted from the first/main issue right now.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message