From gstein@lyra.org Tue Dec 5 03:39:06 2000 Return-Path: Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Delivered-To: mailing list dev@apr.apache.org Received: (qmail 70131 invoked from network); 5 Dec 2000 03:39:06 -0000 Received: from kurgan.lyra.org (198.144.203.198) by locus.apache.org with SMTP; 5 Dec 2000 03:39:06 -0000 Received: (from gstein@localhost) by kurgan.lyra.org (8.9.3/8.9.3) id TAA26618; Mon, 4 Dec 2000 19:41:25 -0800 X-Authentication-Warning: kurgan.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Mon, 4 Dec 2000 19:41:24 -0800 From: Greg Stein To: "William A. Rowe, Jr." 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 Message-ID: <20001204194124.J26208@lyra.org> Mail-Followup-To: "William A. Rowe, Jr." , dev@apr.apache.org References: <20001204155209.E26208@lyra.org> <000201c05e6b$529e94d0$92c0b0d0@roweclan.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <000201c05e6b$529e94d0$92c0b0d0@roweclan.net>; from wrowe@rowe-clan.net on Mon, Dec 04, 2000 at 09:27:38PM -0600 X-URL: http://www.lyra.org/greg/ X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N 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/