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 Tue, 05 Dec 2000 04:09:16 GMT
On Mon, Dec 04, 2000 at 09:53:17PM -0600, William A. Rowe, Jr. wrote:
> > From: Greg Stein [mailto:gstein@lyra.org]
> > Sent: Monday, December 04, 2000 9:41 PM
> > 
> > On Mon, Dec 04, 2000 at 09:27:38PM -0600, William A. Rowe, Jr. wrote:
> > > > 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
> > > >    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?
> ack ... or more specifically, that a p/w _simple_ text file is dependent
> on which platform it is moved between.

We have old password files to deal with. But we can probably make them a bit
more portable. Feel free to work on it :-)

> > 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)
> Can we live with apr_os_crypt and apr_des_crypt, for example?  (== on some
> platforms, something odd on others?)

They would always be separate functions. The crypt() function has a
different prototype than what we would want for apr_des_encrypt(). crypt()
is really only for password encryption (go read the man page), while we
would want to use a general buffer-encryption type of API.

Note that I also call it apr_des_encrypt. DES is a symmetric key algorithm,
but I think we need a second API for decryption (apr_des_decrypt). It is
possible the same API could be used for both, but we can figure that out
if/when we ever integrate DES encryption into apr-util.

For the APR function, apr_crypt() is fine with me. I'm not sure that we need
"os" in there... we don't do that with other APR functions.

> > 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.
> Which is ;-?

Read steps 1-3 at the top of this mail. I'm concerned with shifting MD5 over
to apr-util/src/crypto/  (it is a cryptographic hash, so it goes in crypto).

>  Seriously, if crypt is out there, and we are wrapping it,
> stay away from the ambiguous apr_crypt name :-)

Not sure what is wrong with apr_crypt... It is the APR equivalent for
crypt(). The name makes sense to me...


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

View raw message