Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Errors-To: <wrowe@rowe-clan.net>
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
To: "'Greg Stein'" <gstein@lyra.org>
Cc: <dev@apr.apache.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, 4 Dec 2000 21:53:17 -0600
Message-ID: <000401c05e6e$e77ebc30$92c0b0d0@roweclan.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <20001204194124.J26208@lyra.org>

> 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 :-)