[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 17 Feb 2008 01:43:57 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: welcome
Hi Josh,
On Fri, Feb 15, 2008 at 05:58:45PM -0500, Josh Bressers wrote:
> Here's the current draft of things I've been working on for a while now
> (this has been brewing in my brain for a while)
Thank you for posting this!
I have some comments, see below:
> * Public - only silent when needed
>
> The idea here is to have a group that is made up of individuals interested
> in matters of open source security. The group would be split with two
> distinct functions (vendor-sec is currently one of these). There would be
> a very small group of trusted individuals who would handle sensitive
> embargoed security flaws. While the goal of open source is to be as open
> as possible, there are times that flaws will need to be embargoed for the
> common good. This is best described by situations where it would be
> trivial to write a worm with a given flaw. Ideally we will want to give
> select vendors a few days to patch the flaw before it goes public.
OK, so oss-security (this list) is going to be the public (and much
larger) part of the group, and there's going to be some overlap between
the parts. It is interesting to note that the small-and-trusted part
of the group is not going to be a subset of the large-and-public part:
although this list was announced on vendor-sec, not all vendor-sec
members have decided to join. My understanding is that this is largely
because many vendor-sec members are there "just" to be able to update
their distributions in time for coordinated public disclosure dates -
which is fine because it benefits the end-users.
> * 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"?
> * 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?
> * 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.
> * CVE - Help bridge the gap between CVE and open source
>
> We will have several CNAs on the list. Perhaps get MITRE to work with us
> for quick CVE id assignment, and ideally we could help lessen their load a
> bit.
>
> * Community - Let others help when possible
>
> Right now the open source security universe is a black hole. Hopefully
> by having a public venue we will create an environment that encourages
> outsiders to become involved. The more involved we make the various
> entities, the better the state of open source security should become. We
> love to beat the community drum for open source, but we've largely been
> unable to do this with respect to security. Changing that should bring
> significant benefits.
Sounds great. This should be worth a try.
Thanks again,
Alexander
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.
