mailing list archives
Re: distros & linux-distros embargo period and message format
From: Kurt Seifried <kseifried () redhat com>
Date: Wed, 01 Feb 2012 17:25:32 -0700
On 02/01/2012 04:54 PM, Solar Designer wrote:
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.
Against the certainty that the end of the embargo brings, so we're
putting a potential risk (rediscovery/etc.) against a guarented risk
(details will become available when the embargo ends. I'm not claiming
to know which is better but I think two weeks is already pretty short,
reducing that to say a week only saves 7 days but potentially increases
workload 100% or more (we have half as much time to deal with it).
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.
I think the shortened embargo time is rapidly approaching the limit of
maximum benefit (that is balancing time to fix against the chance of it
becoming public and putting systems/people at risk). Personally I think
hard rules are not a good idea here, I would support guidelines that
have some flexibility, not all cases are the same.
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).
I don't have the data handy but I know most Linux vendors are now
responding to 500-1000 security issues per year and getting the majority
of them fixed by the time the issue goes public or very shortly
thereafter, I'm not sure we can speed this up much (this works tends to
be highly serialized, find the bug, assess the bug, fix the bug, QA the
Also I haven't really seen any cases in the open source world of a leak
of information leading to widespread exploitation/problems (and if there
have been I'd love to know).
Kurt Seifried Red Hat Security Response Team (SRT)