[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120316021811.GA11031@openwall.com>
Date: Fri, 16 Mar 2012 06:18:11 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: running the distros lists
Josh, Kurt, all -
On Thu, Mar 15, 2012 at 08:33:41AM -0400, Josh Bressers wrote:
> 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.
This makes some sense, but:
1. I think that merely proposing a CRD for every reported issue right
away is not a timesink. I could probably be doing it myself, but I'd
like to get other list members more involved in running the list in
general, I feel that I am already contributing by administering the
list setup (so it's not my turn to contribute more), and I think that
someone with a vendor affected by a larger percentage of the issues is
in a better position to propose CRDs.
2. It is bad that embargo periods on the historic vendor-sec were often
pretty long. I don't want the same to be happening on the distros list.
Yes, the reality is that some issues will end up being embargoed for
longer than many of us would have liked, but let's try to reduce the
embargo periods whenever we can and to the extent possible. Proposing a
CRD early on is a step in that direction.
> Trying to get a couple people to do this is going to be a losing battle.
Maybe, but why (in your opinion)?
> We need to think about how to best let the list police itself.
Do you have any specific proposal?
What I am thinking is that with only a few of us being responsible for
doing some well-specified things we will actually have to be doing those
things or be prepared to explain why we failed, apologize for that, and
adjust our actions going forward.
On the other hand, with the list membership at large being responsible
for running the list in accordance with certain goals and policies, no
one in particular is responsible. When things go wrong, there's not
much we can do - no one in particular feels like it's his/her fault, no
one in particular is going to change anything going forward. We can
only choose between ignoring the problem, calling it a non-problem,
shutting the list down, or switching to the "few responsible list
members" scheme that I am proposing now. I simply see no other options.
> 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).
Maybe, but why can't we have a CRD proposed within a day in 100% of
cases? Not all of those initially proposed CRDs will be agreed to, but
at least proposing them without delay is desirable, I think.
> 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.
We already have what I think are reasonable guidelines. We see how
things are going: many of the reported issues linger without even a
proposed CRD for days. I find that unacceptable because at least in
some cases it leads to increased total embargo periods. Thus, I think
we're ready to discuss and hopefully arrive at a solution.
Thanks,
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.
