[Mailman-Developers] config.pck password encryption inconsistencies

[Dave Dewey]

Hello;

I currently run Mailman 2.1.5 on one server, and have web archives using
MHonArc running on a different webserver.  I have shell access to both.
These archives are private, for list subscribers only. 

I am trying to implement .htaccess authentication using the instructions
here: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.007.htp 
I have this script working although it required minor modifications to run
under 2.1.5.  This is a Fedora Core 2 install from source.

The modified script creates the .htpasswd database on the mailmain server
and scp's it to the webserver over a private net.

Here's the issue I can't solve.  It is clear that SOME user passwords in the
lists' config.pck file are encrypted, and some aren't.  This is within the
SAME config.pck, I'm only running one list.  When using 'dumpdb' to
investigate the the users email/passwords, some of the passwords are
definitely clear text.  However, others (including all of my own, for
various test subscriptions) are encrypted.

The problem is that when I then use htpasswd to create the .htpasswd file,
the encrypted passwords are re-encrypted again for use by apache.  Therefore
the only acceptable password for logging into the archives is the encrypted
form.  Here's an example using fake text:

User passwd:  Config.pck entry:   .htpasswd: 	Accepted by Apache:
tree   	      Uasdf!d	 	  ljkjkld       Uasdf!d

When the user's password is in UN-encrypted form in config.pck, everything
works great, eg:

User passwd:  Config.pck entry:   .htpasswd: 	Accepted by Apache:
rock   	      rock	 	    Oad;int    	rock

Using htpasswd's -p switch to add the passwords in clear text doesn't work
either.  Same problem, in that now the Apache password is the then as in the
config.pck, which may or may not be encrypted.

I hope this makes sense.  Any suggestions for dealing with this?  Obviously
users can't be expected to know what the encrypted version of their password
is or might be... Is this the expected behavior (some passwords clear,
others encrypted?). Is this documented anywhere?

dave