Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <88277d60-aa3b-4f06-ac50-54d76aae307f@zmail13.collab.prod.int.phx2.redhat.com>
Date: Thu, 15 Mar 2012 08:33:41 -0400 (EDT)
From: Josh Bressers <bressers@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: running the distros lists

> 
> Kurt - how about my original request for help running the list, though?
> Even if you somehow don't volunteer to notify upstreams (and others),
> making sure that every issue gets a CRD proposed for it ASAP will be of
> help.  Can I at least count on you doing that? ;-)  And maybe someone
> else will volunteer for other sub-tasks (although a per-vulnerability
> rather than per-sub-task split between the several responsible list
> members could work better, I think).
> 

This task strikes me as a timesink that results in minimal value. It's in
the best interest of all list members to fix issues in a timely manner. The
historic vendor-sec never had a serious problem with CRD. They were often
outside of the current proposed 14 day span, but that's just a reality of
how things go. We all have more work to do than time, so some things are
bound to suffer.

Trying to get a couple people to do this is going to be a losing battle. We
need to think about how to best let the list police itself. It certainly
won't be 100% perfect, but I think even an 80% reasonable CRD agreement
goal is acceptable (perfect is the enemy of the good comes to mind).

I would suggest some reasonable guidelines (that are not enforced
strictly), then see how things go for a while. If it's deemed unacceptable,
a better solution can be worked on.

Thanks.

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