[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 22 Mar 2015 12:44:37 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: oss-security@...ts.openwall.com
Subject: Re: membership request to the closed linux-distros security mailing list
* Stuart Henderson:
> On 2015/03/20 08:16, Anthony Liguori wrote:
>>
>> I think the alternative is to formalize what already appears to be the
>> existing practice: disclose distros@ on the existence of a
>> vulnerability but require direct contact for the details of the
>> vulnerability if the submitter/upstream thinks the impact is high.
>
> Are private lists even needed if this policy is taken?
Yes, it is. Often, things are bad enough that just looking at the
software for five minutes is sufficient to rediscover the
vulnerability. Or maybe a couple of different vulnerabilities with
similar impact.
There's also interaction with CVE assignment. The current, working
assignment process requires short embargoes at least. And a certain
subset of reporters cares about the CVE assignment above anything else
because it's a widely-accepted metric for having found something,
which in turn indicates that the reporters have done their job. I
think we can and should reduce the number of embargoes, but we'd have
to address the CVE assignment process for public issues at the same
time.
Reducing the number of embargoes would also help those
quasi-proprietary vendors and show them that building upstream
relationships and tracking their software portfolio are the key tasks,
and not getting a few days advance notice for vulnerabilities. Most
GNU/Linux distributions can fix about anything that's fixable at all
within two or three weeks (and that includes the analysis required to
actually understand the bug). Most quasi-proprietary vendors work on
totally different time scales, and even if they do not have to do the
analysis themselves, a few weeks is nothing to them.
But here's another perspective. Lior Kaplan writes, “Even if the
issue isn't severe, upstream should get a fair chance to fix issue
before making them public.”
<https://liorkaplan.wordpress.com/2015/03/19/cve-assignment-without-upstream-knowledge/>
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.
