You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@httpd.apache.org by Mladen Turk <mt...@mappingsoft.com> on 2001/09/22 20:43:39 UTC

[REWRITE] htpasswd.c

Hi,

Here is my humble attempt to rewrite the htpasswd util.
It has integrated support to manage either flat-files or apr_dbm based user
databases.

Now, there has been some thoughts to make two utils. The standard htpasswd
that deals with flat-file databases and the dbm powered one.

This util supports both, but it can be broken in two utils if that's what we
need.

The other thing is that this util breaks the command line options from
previous Apache1 version. The reason for that is the usage of apr_getopt
instead of custom command line parser from original htpasswd. If we need to
keep the original command line options that can be easily done.

I've tried to write the util as much independent from the stand-alone
application as I could. The reason for that is to enable some parts of code
to get into de apr core itself. IMHO if we have a mechanism for password
validation, then we should have the management code too.

I've tested the code on WIN32 and RH-7.1 platforms only, so I'll appreciate
comments from other platforms.

MT.

RE: [REWRITE] htpasswd.c

Posted by Mladen Turk <mt...@mappingsoft.com>.


> -----Original Message-----
> From: Ian Holsman [mailto:ianh@apache.org]
> Sent: Saturday, September 22, 2001 10:28 PM
> To: dev@httpd.apache.org
> Cc: New-Httpd; William A. Rowe Jr.
> Subject: Re: [REWRITE] htpasswd.c
>
> Hi Mladen.
>
> There is another problem at the moment,
> auth_dbm doesn't need to use apr_dbm to store it's
> password DB.  (I don't even think that it is the default)

Know that.

The apr-util apr_dbm is the only thing that makes sense to me. I know that
there are lots of dbm-alikes out there, and almost all of them has some kind
of ndbm interface. Unfortunately this is true only on the UNIX platforms.
So I come with the common denominator and that is apr_dbm at the moment.

When apr_dbm gets (I hope) some kind of run-time dbm selection mechanism
instead of compile-time, the things will get much more easier.

I have a running port of dbm-1.85 that uses apr instead of unistd.h. When I
tested it on Linux I'll put it for the review. That will solve auth_db
(well, not version 2 and 3 from Sleepycat).

I really didn't test the binary file compatibility between apr-util SDBM and
ndbm that comes with each *NIX box. If you think that they are incompatible
then what is the reason for SDBM in the apr-util at all?
But if they are then I don't see any problem.


MT.

Re: [REWRITE] htpasswd.c

Posted by Ian Holsman <ia...@apache.org>.

Hi Mladen.

There is another problem at the moment,
auth_dbm doesn't need to use apr_dbm to store it's
password DB.  (I don't even think that it is the default)


Mladen Turk wrote:

> Hi,
> 
> Here is my humble attempt to rewrite the htpasswd util.
> It has integrated support to manage either flat-files or apr_dbm based user
> databases.
> 
> Now, there has been some thoughts to make two utils. The standard htpasswd
> that deals with flat-file databases and the dbm powered one.
> 
> This util supports both, but it can be broken in two utils if that's what we
> need.
> 
> The other thing is that this util breaks the command line options from
> previous Apache1 version. The reason for that is the usage of apr_getopt
> instead of custom command line parser from original htpasswd. If we need to
> keep the original command line options that can be easily done.
> 
> I've tried to write the util as much independent from the stand-alone
> application as I could. The reason for that is to enable some parts of code
> to get into de apr core itself. IMHO if we have a mechanism for password
> validation, then we should have the management code too.
> 
> I've tested the code on WIN32 and RH-7.1 platforms only, so I'll appreciate
> comments from other platforms.
> 
> MT.
> 
>

Re: [REWRITE] htpasswd.c

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.

> From: "Mladen Turk" <mt...@mappingsoft.com>
> Sent: Thursday, October 11, 2001 12:27 PM
> 
> > I don't think that htdigest would be so hard to integrate with htpasswd,
> > I'll check that :)

The other point I meant to make (sorry I forgot it) was that the folks
who use htpasswd/htdigest/dbmmanage today already have scripts that invoke
it.  If we change the commands and syntax, we break their existing efforts.

To introduce a (new) unified utility that managed htpasswd/htdigest/db/dbm
files, and _recognized_ the scheme in use, could be a very valuable thing.
But please don't change the semantics in such a way that we strand current
users of these utilities.  Most aren't even comfortable with the script 
hacking required to fix the scripts they use for new arguments, etc.

Also realize, with dbmmanage, that it is built to export and then import
it's file.  Would be very good if that syntax remains unchanged, so that
users can upgrade from dbm to dbm, between 1.3 and 2.0.  I'm not suggesting
we would add this to 1.3, but whatever dbmmanage -save does today, we aught
to be able to reload in 2.0 :)

Bill

Re: [REWRITE] htpasswd.c

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.

From: "Mladen Turk" <mt...@mappingsoft.com>
Sent: Thursday, October 11, 2001 12:27 PM


> I like the sound of htdbm.
> 
> There is other thing that was discussed earlier and that is to drop the
> crypt() from htpasswd.
> As there been said the crypt() is preserved for compatibility reasons only,
> and the preferred hashing scheme is MD5.

That's my understanding, yes.  Please make that a second patch to htpasswd,
and a first patch on top of your htdbm.  If folks disagree later, it's easy
to segregate.

> So IMO the htpasswd util doesn't need that option implemented. I'll put it
> as #if 0...#endif.

No, it needs to be implemented (with some APR_HAS_CRYPT test) but it may be
set off as not-the-default.

> I don't think that htdigest would be so hard to integrate with htpasswd,
> I'll check that :)

Please don't :-?  This will become rapidly confusing.  It's better to posit
the idea first, write the patch second.  It's much less disheartening when
folks tell you up front it's not desired.

First clean up htpasswd, doing what it already did, then in a second patch
adopt the MD5 default.

Then offer up your htdbm, with an MD5 default scheme if you like.

And toss out the idea of merging htpasswd+htdigest.  I suspect alot of us
might find that overly confusing.

The bigger issue is one lots of submitters get caught in (including me.)
Try to make each patch do one thing, so that it's easy to follow the history.

[I don't care about a mass update to a never-released entity like your new
ApacheMonitor.  A module or utility that's been released, e.g. the htpasswd
and htdigest utilities need careful tracking to be able to spot bugs if they
are introduced in later releases.]

Bill

RE: [REWRITE] htpasswd.c

Posted by Mladen Turk <mt...@mappingsoft.com>.

> -----Original Message-----
> From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Thursday, October 11, 2001 4:02 PM
> To: dev@httpd.apache.org; Mladen Turk
> Subject: Re: [REWRITE] htpasswd.c
>
>
> Mladen,
>
>   would you split the new 'idea' of an htdbm manager from this module,
> and provide a seperate patch for your htpasswd fixes?
>
>   I'd like to see these both committed this week.  Right now, we keep the
> htpasswd seperate from htdigest, although they didn't need to be strictly
> seperate.  I'd like to maintain the same seperation for your dbm user
> manager, and commit it.  Guess it's yours, so feel free to name it...
> htdbm, dbmuser, whatever makes the most sense to you ;)
>

I like the sound of htdbm.

There is other thing that was discussed earlier and that is to drop the
crypt() from htpasswd.
As there been said the crypt() is preserved for compatibility reasons only,
and the preferred hashing scheme is MD5.
So IMO the htpasswd util doesn't need that option implemented. I'll put it
as #if 0...#endif.
I don't think that htdigest would be so hard to integrate with htpasswd,
I'll check that :)


MT.

Re: [REWRITE] htpasswd.c

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.

Mladen,

  would you split the new 'idea' of an htdbm manager from this module,
and provide a seperate patch for your htpasswd fixes?

  I'd like to see these both committed this week.  Right now, we keep the
htpasswd seperate from htdigest, although they didn't need to be strictly
seperate.  I'd like to maintain the same seperation for your dbm user
manager, and commit it.  Guess it's yours, so feel free to name it...
htdbm, dbmuser, whatever makes the most sense to you ;)

Bill

----- Original Message ----- 
From: "Mladen Turk" <mt...@mappingsoft.com>
To: <de...@httpd.apache.org>
Cc: "Sterling" <st...@covalent.net>; "William A. Rowe Jr." <wr...@rowe-clan.net>; "New-Httpd" <ne...@apache.org>
Sent: Sunday, September 23, 2001 3:29 AM
Subject: [REWRITE] htpasswd.c


> 
> Since Sterling reported compilation errors on RH when usinig -Werror here is
> the updated version that does't reports any warning on that platform.
> 
> I didn't post the patch but reather entire file since it's not in the CVS.
> 
> MT.
>