apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@mappingsoft.com>
Subject RE: [PATCH] apr_password_validate with LIBEAY des_fcrypt support take 2
Date Mon, 24 Sep 2001 19:42:30 GMT

> -----Original Message-----
> From: Ryan Bloom [mailto:rbb@covalent.net]
> Sent: 23. rujan 2001 17:09
> To: William A. Rowe, Jr.; Mladen Turk; Justin Erenkrantz
> Cc: APR Dev List
> Subject: Re: [PATCH] apr_password_validate with LIBEAY des_fcrypt
support take 2
> > > > Nothing happens!
> > > > It falls back to the original behavior if the dll coudn't be
loaded at
> > > > runtime.
> > >
> > > I dislike this.  My concern is that if you take the same binary to
> > > different Windows machines, you will get two different results.
[Mladen Turk] 
Don't we always do :-) ?
> > > I would prefer to just have APR always use md5 hashes to protect
passwords.  We
> > > could basically just document the des option as depricated, and
> > > provided for backwards compat with older systems.
[Mladen Turk] 
OK. I can accept that. But could you guys vote on that or whatever is
needed to make a decision, so that someone willing to help doesn't waste
time going into dead ends. I don't recall seeing that thoughts before.
On the other hand why not be able to be a backward compatible on WIN
too? That is the purpose of the patch I wrote, to enable you to be a
compatible if that's what you _want_.
Backward compatibility IMO should be defined in compile time and stated
as such in the documentation, so my suggestion is to drop the crypt from
other platforms too, and live it as a compile-time option, and the
password validation would be consistent on all platforms.

> >
> > Huh?  Are you suggesting that des is depricated on Win32, or _ALL_
> > platforms?
> I'm suggesting that DES is depricated on all platforms, but APR still
> a way to use DES on non-windows platforms, for backwards compat.
[Mladen Turk] 
If MD5 hashing is going to be the only core password protection, then we
should drop all the other algorithms from the htpasswd utility too.
Further more IMO if there is passwd_verify then there should be
passwd_make, just like there is file_create and file_delete. That would
require only couple of lines of code to wrap the apr_md5_encode, and
made password management utils a lot simpler and cleaner from user point
of view.


View raw message