apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@rkbloom.net>
Subject Re: apr_password_validate on win32 silently mishandles crypted hashes
Date Thu, 27 May 2004 00:13:48 GMT
On Wed, 26 May 2004, Stas Bekman wrote:

> rbb@rkbloom.net wrote:
> > Portable doesn't mean what most people think in means in APR.  It means
> > the code _should_ work on all platforms.  It doesn't mean that the data
> > will be processed identically on all platforms hwoever.  In this case, you
> > are asking windows to validate a password that it can't encrypt.  That
> > isn't going to work.
> And according to you definition it is not portable. Since it _should_ work,
> but it doesn't.

Nope, it shouldn't work, and it doesn't.  You are passing a crypt()
encrypted password to a function that, on Windows, doesn't understand
crypt.  APR doesn't mean that all platforms will support all possible
data.  In this case, APR on windows can't process crypt() encrypted

> > What we do in this case, is apr_password_validate uses either crypt, md5,
> > or base64, depending on the input.  There should be a function in APR to
> > encrypt passwords (not sure if there is, and I can't find one in a quick
> > search).
> >
> > But, do not expect that the details will work cross-platform, just the
> > code.
> In which case the code doing crypt verification doesn't belong to
> apr_password_validate. A quick grep of the Apache source shows that it's only
> used by the Apache support utils and should be moved there verbatim.

APR isn't just Apache anymore.  This API exists and may be in use by other
projects using APR.

> If you want to support crypt, include the implementation of fcrypt() on those
> platforms that don't carry crypt.

We have discussed including a crypt implementation in the past and
rejected it, but I don't really remember why.  I think the problem here,
is that we have different ideas of what is desired.  I don't have any
desire to support crypt().  We support crypt() for backwards compatibility
for Apache, but that doesn't mean that our goal is to support crypt.

> At the moment apr_password_validate is half-baked API with very vague docs.

I'm sorry, but that just isn't true.  The API isn't half-baked at all.  It
just doesn't work the way you expect it to work.  As for the docs, yes
they could probably use some work.


View raw message