Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Feb 2008 17:58:45 -0500
From: Josh Bressers <>
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)


* 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

    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

* 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.


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.