oss-security - Re: charter

Openwall Project		/home Owl JtR Pro crypt pam_passwdqc tcb phpass scanlogd popa3d msulogin / Linux BIND / advisories presentations / services donations / wordlists passwords / NEWS community lists Wiki CVSweb mirrors signatures
bringing security into open environments

Password Recovery Resources on the Net

[<prev] [next>] [<thread-prev] [thread-next>] [month] [year] [list]

Date: Tue, 19 Feb 2008 14:50:03 -0500
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com, Solar Designer <solar@...nwall.com>
Subject: Re: charter - advisories

> On Tue, Feb 19, 2008 at 10:09:23AM -0700, Vincent Danen wrote:
> > Yeah, I noticed this as well.  I think advisories should be kept off the
> > list, for the same "signal-to-noise ratio" principal as bugtraq and FD.
> 
> For now, I've edited the charter draft as follows:
> 
> Security advisories aimed at end-users only are not welcome (e.g., those
> from a distribution vendor announcing new pre-built packages).  There has
> to be desirable information for others in the Open Source community
> (e.g., an upstream maintainer may announce a new version of their
> software with security fixes to be picked up by distributors).
> 
> If anyone can word it better, please do.
> 
> > It may be a better idea, if desired, to make a separate list that is a
> > fully moderated (or possibly a reject-all with exceptions) list specific
> > to carrying vendor advisories.
> 
> Yes, that was my idea too.  However, now that we mention the distinction
> between two kinds of advisories (those for end-users only vs. those
> useful to others as well), I am not sure which of these we want to go to
> that other list.  Should we create a list for advisories that are useful
> for us, then change the above guideline to "no advisories" for the main
> oss-security list?  Or should we create a list for both kinds of
> advisories?  In the latter case, should we ban the useful advisories
> from the main oss-security list or should these be CC'ed to both lists?
> Or should we create two new lists?..
> 

Let's leave it be for now.  Given how much speculation this is causing, I'm
hesitant to solve a problem that doesn't yet exist.

I like the above text, that sounds nice.  If this proves to be a problem at
a later date, we can create some new lists.

-- 
    JB

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