[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <550C46E3.4010806@redhat.com>
Date: Fri, 20 Mar 2015 10:12:19 -0600
From: Kurt Seifried <kseifried@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: membership request to the closed linux-distros
security mailing list
On 03/20/2015 09:55 AM, Marcus Meissner wrote:
> On Fri, Mar 20, 2015 at 08:54:29AM -0700, Anthony Liguori wrote:
>> On Fri, Mar 20, 2015 at 8:50 AM, Stuart Henderson <stu@...cehopper.org> wrote:
>>> 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?
>>
>> I think there's a lot of value in being able to just send a low-medium
>> impact issue to a single list of groups that have gone through some
>> level of vetting without needing to respond directly to individuals
>> and making value judgements.
>>
>> I also think it's helpful to have a single point of contact so that an
>> upstream isn't dealing with 10 different people from a single
>> organization asking for details.
>
> Why not just publishing a low - medium impact vulnerability directly?
>
> Embargoe handling alwas also has some overhead , which is not necessary in such cases.
>
> Ciao, Marcus
Agreed 100%, we're changing from the old default of "everything should
be embargoed unless it can be public" to "everything should be public
unless it must be embargoed" (and ideally a short embargo like this
weeks OpenSSL one). It creates a LOT less work. Especially with the
prevalence of GitHub which has no concept of private issues/commits, so
fixing things privately means you have to work outside of your normal
workflow which is insane for anything that isn't important/critical.
--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
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.
