You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2000/12/04 23:46:20 UTC
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
Three bits I didn't intend to commit, please comment if they
cause problems:
> wrowe 00/12/04 14:26:56
>
> Log:
> A brand new (and -greatly- simplified) test build
> environment for Win32
>
> Revision Changes Path
> 1.30 +2 -7 apr/test/Makefile.in
>
> Index: Makefile.in
> ===================================================================
> -TARGETS= testmd5@EXEEXT@ \
> - testfile@EXEEXT@ \
> +TARGETS= testfile@EXEEXT@ \
md5 (et. al.) are all moving to aprutil, correct?
> Index: sendfile.c
> ===================================================================
> -#include <sys/uio.h>
I'm guessing no one required this anymore, but please test.
> Index: testmmap.c
> ===================================================================
> -#include <unistd.h>
This might be bad, advise of problems and I will back out the change.
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
Posted by Greg Stein <gs...@lyra.org>.
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 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?
>
> 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...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> 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 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?
ack ... or more specifically, that a p/w _simple_ text file is dependent
on which platform it is moved between.
> > 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.
Cool, that's what I'd been led to believe.
> > 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.
Eh... now we are talking :-) I have no issue with providing the 'platform
native' crypt as it's own entry point.
> 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?)
> 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 ;-? Seriously, if crypt is out there, and we are wrapping it,
stay away from the ambiguous apr_crypt name :-)
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
Posted by Greg Stein <gs...@lyra.org>.
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 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/
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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
> 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 or
> apr_crypt() as appropriate.
Why are we proliferating this problem, again, and still?
I understand that there are no significant export issues remaining with the
original crypt() functions, and they are available under free bsd license,
correct? This is a portability issue in itself, though one that could be
very reasonably implemented/handled in aprutil.
> 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.
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
Posted by Greg Stein <gs...@lyra.org>.
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)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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
Posted by rb...@covalent.net.
> > > (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 rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
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
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Dec 04, 2000 at 03:11:54PM -0800, rbb@covalent.net wrote:
> > > I would really prefer that we keep some way to encode passwords in
> > > APR. This is a portability issue, so -1 (vote, not veto) for removing
> > > md5 from APR.
> >
> > I'm +1 on moving them to apr-util ... MD5 hashing is entirely portable. That
> > is also where SHA-1 hashing is located.
> >
> > (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.
> 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.
>...
> 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.
The only thing that uses MD5 in APR is the UUID generation on non-Windows
platforms. However, it has no real requirement to do so. The MD5 hashing was
simply used as a way to create random data.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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
Posted by rb...@covalent.net.
> > I would really prefer that we keep some way to encode passwords in
> > APR. This is a portability issue, so -1 (vote, not veto) for removing
> > md5 from APR.
>
> I'm +1 on moving them to apr-util ... MD5 hashing is entirely portable. That
> is also where SHA-1 hashing is located.
>
> (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. Plus, for backwards compatability with 1.3, APR
will need to understand how to check for MD5 passwords. Unless we can
find some way to get APR to encode MD5 passwords without putting MD5 in
APR, this needs to remain in APR.
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.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
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
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Dec 04, 2000 at 02:54:33PM -0800, rbb@covalent.net wrote:
>
> > > Index: Makefile.in
> > > ===================================================================
> > > -TARGETS= testmd5@EXEEXT@ \
> > > - testfile@EXEEXT@ \
> > > +TARGETS= testfile@EXEEXT@ \
> >
> > md5 (et. al.) are all moving to aprutil, correct?
>
> I would really prefer that we keep some way to encode passwords in
> APR. This is a portability issue, so -1 (vote, not veto) for removing
> md5 from APR.
I'm +1 on moving them to apr-util ... MD5 hashing is entirely portable. That
is also where SHA-1 hashing is located.
(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)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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
Posted by rb...@covalent.net.
> > Index: Makefile.in
> > ===================================================================
> > -TARGETS= testmd5@EXEEXT@ \
> > - testfile@EXEEXT@ \
> > +TARGETS= testfile@EXEEXT@ \
>
> md5 (et. al.) are all moving to aprutil, correct?
I would really prefer that we keep some way to encode passwords in
APR. This is a portability issue, so -1 (vote, not veto) for removing
md5 from APR.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------