[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 01 Feb 2012 17:25:32 -0700
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
CC: Solar Designer <solar@...nwall.com>
Subject: Re: distros & linux-distros embargo period and message
format
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
software, etc.).
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).
> Thanks again,
>
> Alexander
--
Kurt Seifried Red Hat Security Response Team (SRT)
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.
