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

[Marc MERLIN]

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