On Thu, Jan 03, 2002 at 02:14:11PM -0500, Barry A. Warsaw wrote:
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.
Sorry if i wasn't clear. Yes, the site admin password entered once and working on all the lists would be great. Now, if I admin 10 lists with the same list password, and that works too, even better, but I don't need this as bad.
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.
I'll have to look.
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
No, I just took your docs for granted (they say you need to regen everything after the upgrade). If it works, great :-)
I anticipated your pain (benefits of joyriding in Guido's time machine), so if this doesn't work, it's a bug.
Cool.
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).
I saw the changelog in 2.1a4 and it looked like what I was looking for, but I wasn't able to see the reason why a user was disabled in admin/listname/members/list The idea is to be able to script remove or re-add everyone who disabled themselves (only) or who got disabled due to bounces (only). It seems that you've implemented this now, I'm just not sure where the info is yet.
Marc
Microsoft is to operating systems & security .... .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f@merlins.org for PGP key