Openwall Project   /home  Owl  JtR  Pro  crypt  pam_passwdqc  tcb  phpass  scanlogd  popa3d  msulogin  /  Linux  BIND  /  advisories  presentations  /  services  donations  /  wordlists  passwords  /  community  lists  wiki  CVSweb  mirrors  signatures
bringing security into open environments
 
Order Openwall GNU/*/Linux 2.0 on a CD with delivery worldwide
[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]
Date: Wed, 9 Apr 2008 19:14:17 -0600
From: Vincent Danen <vdanen@...sec.ca>
To: oss-security@...ts.openwall.com
Subject: Re: list: members vs. read-only subscribers

* [2008-04-07 13:35:53 -0400] Josh Bressers wrote:

>> It appears that Josh and Vincent have expressed the same opinion in the
>> quotes above.  Unfortunately, ezmlm-idx does not have a notion of having
>> different types of subscribers to a list - "members who can post" vs.
>> "read-only subscribers".  Yet, if this is really what we want (any other
>> opinions?), we may be able to achieve it in one of two ways:
>> 
>> 1. Use the "allow" list feature to specify the addresses of "full
>> members".  Unfortunately, in my experience the "allow" list is used for
>> lists that are moderated for non-subscribers only (to allow some
>> non-subscribers or alternate addresses of subscribers to post without
>> moderation), not for those that are also moderated for subscribers.
>> I have not looked into whether this would be easy to fix or not - but I
>> or someone else at Openwall can look into it if needed.  It might turn
>> out that the fix is trivial.
>> 
>> 2. Setup a second list for the read-only subscribers, and subscribe that
>> list to the main one.
>> 
>
>Here is my proposal, technical issues aside (we are smart people, we'll
>figure something out).
>
>* The current member list can post unmoderated
>* New subscribers (anyone can subscribe) will be moderated by default, but
>  can have the moderation flag lifted when the prove to be useful
>  contributors (we need to define what a useful contributor is)
>* Non members can post, but will be moderated (if spam is an issue, we
>  could consider just throwing this stuff out, but I'd really like to avoid
>  it if possible)

This works for me.

>I think that this should appear as one list to the end user.  If we end up
>using some bizarre solution with multiple lists to work around the
>ezmlm-idx shortcomings, we need to ensure that this is not obvious to the
>end users.  Users should be able to hit reply and the right thing just
>happens.

I agree.  My solution was perhaps a little too convoluted and/or
paranoid... take your pick.  =)

>For the wiki, I'd say just make it a free for all.  If they take the time
>to create an account, let them make changes, we'll keep an eye on what gets
>modified.  We can deal with spam if it becomes a problem.

I can deal with this too.  There's, what, a half-dozen of us that are
getting notices of changes to the wiki so any problems should be picked
up and corrected pretty quickly.

>If you don't like this, speak up now, otherwise, I think it would make
>sense to find a solution that fits this model.

It's fine with me, and I see Solar is ok with it as well so I say do it
(I don't see anyone else having spoken up one way or the other, and it's
taken me a few days to get to this... release week always causes time
shortages).

-- 
Vincent Danen @ http://linsec.ca/

[ CONTENT OF TYPE application/pgp-signature SKIPPED ]

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Hosted by DataForce ISP - Powered by Openwall GNU/*/Linux