On Mon, Dec 04, 2000 at 03:39:23PM -0800, [EMAIL PROTECTED] wrote: > > > > (the standard crypt() is generally non-portable and would remain in APR; > > > > that should solve Ryan's request for a way to hash [not encode] > > > > passwords) > > > > > > We don't have a crypt routine, and there has been no discussion of putting > > > crypt into APR so far. > > > > htpasswd uses crypt(), but that is quite platform specific. It probably > > should use an APR cover for it. > > htpasswd also uses MD5's, based on run-time arguments.
I was talking about crypt() needing to be in APR. Of course I knew htpasswd uses MD5. > > > Plus, for backwards compatability with 1.3, APR > > > will need to understand how to check for MD5 passwords. > > > > APR doesn't do this. Apache does. Since MD5 will be available in apr-util, > > there shouldn't be any problem. > > Look again. The validate_password function is in APR. All Apache does is apr_validate_password is in apr_md5.c. It would move. > call out to PR to determine if two passwords are the same. We could move > that function to apr-util, but that seems wrong to me. I seriously > dislike having two different libraries providing the two different ways we > encode passwords. I'm not sure that I follow... which two libraries? 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. > > > Otherwise, andbody who chose to create MD5 password files will need to > > > re-create their password files for 2.0. I am -1 for forcing them to do > > > that, and that is a veto. > > > > I would agree with that veto, except it isn't needed :-) The MD5 password > > files are managed by Apache... not APR. > > No, currently they are managed by APR, as long as the validate_password > routine is in an APR library, this is an issue. The files are not. Just the apr_validate_password function. The only reason that I can gather it exists in APR is because of the non-portability of the crypt() function. apr_validate_password has some platform #ifdefs in there that can easily go away if apr_crypt() existed. (and apr_crypt would also make htpasswd.c more portable) Cheers, -g -- Greg Stein, http://www.lyra.org/
