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: 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:27:38 GMT
> 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 understand that there are no significant export issues remaining with the
original crypt() functions, and they are available under free bsd license,
correct?  This is a portability issue in itself, though one that could be
very reasonably implemented/handled in aprutil.

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

Mime
View raw message