At 07:34 AM 5/27/2004, Geoffrey Young wrote:
>> I beg your pardon, gentlemen. Would you be so kind to decide first
>> between yourself whether this is a bug or not? According to Ryan it's
>> not a bug, according to your comment above, Bill, it is.
>
>while I've been up most of the night, so I might not be thinking clearly, it
>seems as though if someone were to move a unix-generated crypt .htpasswd
>file to win32,
Whoa - nobody every promised file compatibility, only functionality
on the same machine. That is not a problem. In apache 2.0 we
went to md5 hashes for *exactly* this reason, across all platforms,
by default.
Even Un*x'es don't have consistent implementations of crypt()!!!
Some are 16 and some are 32 bit seeds, etc.
The @bug should not say "Win32 yadda yadda" - but it should
spell out that different platforms will support different password
storage formats.
>mod_auth's call to apr_password_validate would end up simply
>comparing the two values for equality.
That's wrong, IIRC we test md5's/sha1 first (???). If you want to
drop support for plaintext storage in APR 1.0 - I'd strongly back
that move.
Bill
> meaning that passing the actual hash
>as cleartext would succeed. at least that's what I see when I boil down the
>logic.
>
>APU_DECLARE(apr_status_t) apr_password_validate(const char *passwd,
> const char *hash)
>{
>...
> else {
> /*
> * It's not our algorithm, so feed it to crypt() if possible.
> */
>#if defined(WIN32) || defined(BEOS) || defined(NETWARE)
> apr_cpystrn(sample, passwd, sizeof(sample) - 1);
>...
> return (strcmp(sample, hash) == 0) ? APR_SUCCESS : APR_EMISMATCH;
>}
>
>--Geoff
