[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18993.1203116325@devserv.devel.redhat.com>
Date: Fri, 15 Feb 2008 17:58:45 -0500
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: welcome
>
> Josh et al. - now it's your turn. :-)
>
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)
Goals:
* 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.
* 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
* 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.
* 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
* 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.
--
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.
