[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 16 Feb 2008 21:39:04 -0500
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: welcome
> > * Organized - Not a mishmash of undecided people. Have clear goals and
> > procedures.
> >
> > There will be a wiki that contains the static information with respect to
> > how things are handled. Some issues that will need deciding are:
> >
> > 1) How are new members accepted
> > 2) When do we kick out unresponsive members
> > 3) How do we deal with people who develop bad attitudes
>
> This sounds good, except that I see no need to "kick out unresponsive
> members". If they like to listen to our conversations in real time
> (rather than browse the archives) and maybe learn from them - this can
> only be good. Of course, active contribution would be even better.
> So is this "kick out policy" an attempt to encourage contribution?..
>
> Or were you speaking of a vendor-sec equivalent - not this list, but
> perhaps yet another list to be created for the small-and-trusted part of
> the group? If so, how would that differ from vendor-sec itself? Would
> it differ in that any (trusted?) Open Source projects would be accepted,
> not just distribution "vendors"?
We can probably disregard the whole kick out bits. That really would only
apply to a private list that deals with sensitive information. I don't
think there is a benefit to creating a private list at this time, as
vendor-sec exists and is functional.
>
> > * Active - discuss flaws (not a bunch of sponges)
> >
> > We want a group that is responsive and active with respect to the handling
> > of flaws. There will always be a subset of members that don't care about
> > a certain flaw and this is fine, but if someone is always silent, how are
> > they a benefit? Members should be encouraged to participate in
> > discussions and analysis.
>
> The same comments apply here.
>
> Yes, we would like to see a lot of active members, but do we really need
> to kick out the sponges, would that be of benefit?
No, there isn't a benefit in this instance. I do think that encouraging
everyone to contribute in some meaningful manner is a good goal. Anytime
you have a list full of smart people, the new people are usually quite
intimidated and afraid to engage. We need to be mindful of this.
>
> > * Educate - many open source groups suck at security
> >
> > Create several documents that are helpful to the open source community
> >
> > 1) How to report a security flaw
> > 2) How to accept security reports from researchers
> > 3) Basic ideas behind having a security response team
>
> Right - all of this should go on the wiki, and any discussions may occur
> in here.
Yes. I have some notes on this as well. I've been pondering how best to
present this data for quite some time, and have unsuccessfully peddled a
presentation to several conferences.. I'll have to dig out my old notes
(which really means find them in the file ghetto that is my ~).
Thanks for the feedback.
--
JB
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
