On Mon, Dec 04, 2000 at 09:53:17PM -0600, William A. Rowe, Jr. wrote: > > 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.
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/
