my top 3 wishlist for mailman cvs
First, of all, I'd like to say that I really like many of the changes in improvements in mailman cvs, some of them will same me a lot of time with not having to deal with confused users anymore :-)
I however, have 3 items left on my wishlist :-)
#1 Very big feature request: The main list admin's cookie should be valid for all the lists. Having to retype the list password over and over again as I hop from list to list is very tiring.
#2 Is there any way to have mailman still understand admin password in crypt/md5 format? It could read them and only generate the new kind. Resetting 16,000+ list admin passwords on sourceforge.net is going to be a major showstopper (I know, you can regenerate all of them and Email them automatically, but still...)
#3 I'd really like to see a nomail field and a disabled field (one settable by the user, one set by mailman when it disables a member)
Thanks, 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
On Mon, Dec 10, 2001 at 01:33:48AM -0800, Marc MERLIN wrote:
First, of all, I'd like to say that I really like many of the changes in improvements in mailman cvs, some of them will same me a lot of time with not having to deal with confused users anymore :-)
I however, have 3 items left on my wishlist :-)
#1 Very big feature request: The main list admin's cookie should be valid for all the lists. Having to retype the list password over and over again as I hop from list to list is very tiring.
I meant the site password. If I authenticate with the site password, I should get a magic cookie that lets me in all the lists.
If some lists happen to share the same password and somehow by typing the list password on one, I can get on other ones if they share the same password, that would be even better, but I don't need that near as bad.
Thanks :-) 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
"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
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
"MM" == Marc MERLIN <marc_news@vasoftware.com> writes:
MM> Sorry if i wasn't clear. Yes, the site admin password entered
MM> once and working on all the lists would be great. Now, if I
MM> admin 10 lists with the same list password, and that works
MM> too, even better, but I don't need this as bad.I've added a new configuration variable to Defaults.py.in, called ALLOW_SITE_ADMIN_COOKIES. Set this to true and authenticating to a list admin login page with the site password, and Mailman will drop a cookie representing the site authentication. Thus, authenticate once and you can get into every list. The default value of this variable is 0.
-Barry
On Sunday 06 January 2002 03:00, you wrote:
MM> Sorry if i wasn't clear. Yes, the site admin password entered MM> once and working on all the lists would be great. Now, if I MM> admin 10 lists with the same list password, and that works MM> too, even better, but I don't need this as bad.
I've added a new configuration variable to Defaults.py.in, called ALLOW_SITE_ADMIN_COOKIES. Set this to true and authenticating to a list admin login page with the site password, and Mailman will drop a cookie representing the site authentication. Thus, authenticate once and you can get into every list. The default value of this variable is 0.
Woohoo!!!
On Sun, Jan 06, 2002 at 03:00:05AM -0500, Barry A. Warsaw wrote:
I've added a new configuration variable to Defaults.py.in, called ALLOW_SITE_ADMIN_COOKIES. Set this to true and authenticating to a list admin login page with the site password, and Mailman will drop a cookie representing the site authentication. Thus, authenticate once and you can get into every list. The default value of this variable is 0.
-Barry
I had to clear some of my cookies for the site in question, but after that it worked fine. Thanks.
I also had to get back to you as to whether a mailman upgrade broke the exisiting crypted admin passwords. While the upgrade of one my of my sites to mm 2.1a3 seemed to have broken that, I just checked that the upgrade of another site I just completed didn't cause problems and the old passwords worked.
Thanks, 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
participants (4)
-
barry＠zope.com -
Marc MERLIN -
Marc MERLIN -
Phil Barnett