[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Feb 2012 03:54:03 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: distros & linux-distros embargo period and message format
Marc,
Thank you for your feedback.
On Wed, Feb 01, 2012 at 04:02:54PM -0500, Marc Deslauriers wrote:
> A week is a pretty short delay to prepare updates and perform the
> necessary QA to get an issue out on time. Why are you pushing to get the
> maximum reduced?
Why shorter embargo periods are preferable: vendors who are ready to
push out their updates first don't have to sit on those updates waiting
for others, users get their fixes sooner, the potential for leaks (or
rediscovery) and exploit development in the wild before a fix is out is
reduced, the potential for a vendor inadvertently releasing before the
CRD is reduced (and in case this happens anyway, other vendors are
likely "more ready" by that time since they knew the CRD was sooner),
fewer embargoed issues are being tracked at the same time (less work,
lower risk of errors).
Of course, this is a tradeoff - just like the very existence of such
closed lists is.
Why 7-11 days: a few issues were recently handled within 7 days fine -
such as the sudo issue (easy fix provided by upstream and not needing
much QA) and the Linux kernel /proc/<pid>/mem issue (vendors had to
hurry up because the issue was mostly public). So this may be realistic
at least as a target (hence my wiki page edit) or maybe also as the
maximum (hence my proposal). Additionally, the original maximum of 14
days may be seen as potentially including the extra days needed based
on day-of-week: it is one week normal + some days from the other week
when needed by day-of-week. So maybe me trying to meet the reality
(seen on a few occasions) by extending this to 14-19 days was wrong, and
I instead should have proposed 7-11 days. Hence the belated proposal.
Why me: I feel that it's my duty as list admin to propose the smallest
maximum embargo period that list members might be willing and able to use.
Why I am making this proposal now: this is triggered by a certain
off-list discussion I just had; unfortunately, the other party does not
permit me to post more about it. However, as I wrote above, I feel that
I have good reasons to give this proposal a try (see if it's acceptable
or not) regardless of what triggered these thoughts now.
> Reducing the maximum will just result in having everyone miss the
> embargo date and putting users at risk.
It's not that simple.
Not "everyone" will miss the CRD. Clearly, if some vendors on the list
are comfortable with a shorter embargo they either expect to meet the
CRD or find the issues for which they miss the CRD not important enough
to fix before CRD anyway.
I already provided some answers to "why" above, and here's one more: the
change may also result in vendors' processes being adjusted to meet the
faster pace. I am unsure to which extent this is positive overall,
though (considering that those changes may have side-effects).
Thanks again,
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.
