> > > (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. > > 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 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. > > 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. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------
