"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