[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 2 Feb 2012 04:54:31 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: distros & linux-distros embargo period and message format
On Wed, Feb 01, 2012 at 05:25:32PM -0700, Kurt Seifried wrote:
> On 02/01/2012 04:54 PM, Solar Designer wrote:
...
> > 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
We don't really have a choice as to the details becoming public - we
only have (limited) choice as to when.
> but I think two weeks is already pretty short,
OK, thanks for sharing your opinion.
> 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).
Below in this same message you wrote that "most Linux vendors are now
responding to 500-1000 security issues per year", which means that you
almost always have multiple issues being worked on in parallel. Thus,
there should be _no_ increase in workload because if you have to work
on each issue twice faster, you have twice fewer issues to work on at
the same time. So the workload should stay roughly the same.
On the other hand, the "500-1000 security issues per year" figure might
not be relevant - I'll comment on that below.
> 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.
Some people would prefer no rules/guidelines at all - but in that case
use of a public list right away is likely better. ;-)
More to the point, I am not proposing completely removing the
flexibility. With a maximum of 7-11 days, the preference may be even
lower than that - like 4 days. Not surprisingly, you don't seem to like
this - but I think I should have asked anyway.
> 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,
How many of these are embargoed? I think maybe 50 or so? This still
leaves one embargoed issue handled every week, on average, which may be
enough not to significantly increase the workload with a shorter embargo
(one issue handled per week or two issues handled per two weeks -
almost the same thing).
> 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.).
In general, yes. However, the "find" step is usually mostly done by the
time the issue gets to the list, and the QA team might work more closely
with the security team (maybe, or maybe not). I can see that
speculatively testing non-final fixes from the security team may
increase the total workload, though (in case the security team chooses
to revise the fix for its own reasons). This might add cost to the
vendor, but there's also a benefit: quicker fixes to the users, other
vendors not having to wait. There might even be a business/commercial
justification to this change.
> 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).
This argument, assuming that it's true, also means that there's little
to lose by posting to a public list right away or by not having fixes
ready by a CRD in some case.
...or do you feel that a leak to certain unintended parties who may
exploit the issue to a limited scale (and choose not to make the issue
public) is less of a problem than publication of the issue (which may
result in widespread exploitation)? This is non-obvious. While in the
former case fewer systems may be compromised, in the latter case
experienced people and companies with experienced IT security staff
(capable of more than just installing vendors' patches) are given a
better chance to defend their systems.
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.
