On Thu, 27 May 2004, Geoffrey Young wrote: > > > This should move to the httpd list > > um, ok, but it's not necessarily a .htpasswd specific issue. anyone trying > to use apr_password_validate on win32 could potentially run into this. > > the snag, as I see it, is that the fallback position on systems with crypt > is crypt, while the fallback for systems that don't understand crypt is a > simple string comparison. I think that is incredibly misleading for users > of those latter platforms - it goes beyond the simple platform nuances we > all accept and into "oh, no! that's not what I wanted!" > > since the comment for the function is currently > > * Validate any password encypted with any algorithm that APR understands
Right, which Stas has already posted a patch to fix. > and APR currently doesn't understand crypt for win32, then I would suggest > that it is better to return APR_EMISMATCH outright. if people wanted a > simple string match they could do it themselves, right? It would be better in a perfect world. However, we don't live in a perfect world. We live in a world where we need to support legacy apps, and in this case, we need to support legacy Windows .htpasswd files that used plain text. Could we tell Apache to do that? Sure, but this function should do the work, and it was moved into APR, so we are stuck. If you really want to fix this, remove this method from APR all together. Provide a series of functions to md5 passwords, sha1 passwords, crypt passwords. Then, Apache can re-implement this quickly and easily. The crypt check can return APR_ENOTIMPL on Windows, and everything becomes happy happy. I never liked having this stuff in APR, but it is here now, so we either live with supporting legacy httpd stuff, or we remove the function all together. But, this function's real goal is MD5 and SHA1 password verification. Anything else is just a bonus for Apache legacy support. That is documented with Stas' patch, so we can drop this now, right? Ryan
