[Mailman-Developers] my top 3 wishlist for mailman cvs

[Barry A. Warsaw]

>>>>> "MM" == Marc MERLIN <marc_news@valinux.com> writes:

    MM> First, of all, I'd like to say that I really like many of the
    MM> changes in improvements in mailman cvs, some of them will same
    MM> me a lot of time with not having to deal with confused users
    MM> anymore :-)

Yay!

    MM> I however, have 3 items left on my wishlist :-)

    MM> #1 Very big feature request:
    MM> The main list admin's cookie should be valid for all the
    MM> lists. Having to retype the list password over and over again
    MM> as I hop from list to list is very tiring.

Would the site admin password suffice or are you really looking for
a different password.  The site list's password could serve this role,
but I sofrt of see it as a hack.

Note that until now I've avoided cookie-fying the site password
token when authenticating using the site password, but that's mainly
based on some vague fear that if there's a hole in Mailman's security
mechanism, accepting a site password cookie token would leave the
whole list vulnerable.  I'm not aware of such an exploit of course.

If this is really something you want, I think you could add it pretty
easily to SecurityManager.py.

    MM> #2 Is there any way to have mailman still understand admin
    MM> password in crypt/md5 format? It could read them and only
    MM> generate the new kind.  Resetting 16,000+ list admin passwords
    MM> on sourceforge.net is going to be a major showstopper (I know,
    MM> you can regenerate all of them and Email them automatically,
    MM> but still...)

Have you tested this?  I think this is already in there.  MM2.1
should, failing the sha comparison, do an md5 and then a crypt
compare.  If any of them hit, it re-stores the list admin password
using the sha hash (it /knows/ the cleartext password because it was
sent over the wire in the form data, so it knows what to sha hash and
re-store).

I anticipated your pain (benefits of joyriding in Guido's time
machine), so if this doesn't work, it's a bug.

    MM> #3 I'd really like to see a nomail field and a disabled field
    MM> (one settable by the user, one set by mailman when it disables
    MM> a member)

Hmm, can you describe a use case for why you'd want to split these,
presumably in the membership summary page?  Did you see the idea in
cvs based on Dan's suggestion (that an abbreviation of the reason is
shown next to the nomail checkbox).

-Barry