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 Mon, 04 Dec 2000 23:52:09 GMT
On Mon, Dec 04, 2000 at 03:39:23PM -0800, rbb@covalent.net 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)


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

View raw message