On Mon, Dec 04, 2000 at 09:27:38PM -0600, William A. Rowe, Jr. wrote: > > From: Greg Stein [mailto:[EMAIL PROTECTED] > > 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/
