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.