> From: Greg Stein [mailto:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > > 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 :-)
