[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190711203500.GB10104@sasha-vm>
Date: Thu, 11 Jul 2019 16:35:00 -0400
From: Sasha Levin <sashal@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: Greg KH <gregkh@...uxfoundation.org>, corbet@....net,
solar@...nwall.com, keescook@...omium.org, peterz@...radead.org,
tyhicks@...onical.com, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Documentation/security-bugs: provide more information
about linux-distros
On Thu, Jul 11, 2019 at 06:09:21PM +0100, Will Deacon wrote:
>On Thu, Jul 11, 2019 at 07:07:32PM +0200, Greg KH wrote:
>> On Thu, Jul 11, 2019 at 12:36:37PM -0400, Sasha Levin wrote:
>> > Provide more information about how to interact with the linux-distros
>> > mailing list for disclosing security bugs.
>> >
>> > First, clarify that the reporter must read and accept the linux-distros
>> > policies prior to sending a report.
>> >
>> > Second, clarify that the reported must provide a tentative public
>> > disclosure date and time in his first contact with linux-distros.
>> >
>> > Suggested-by: Solar Designer <solar@...nwall.com>
>> > Signed-off-by: Sasha Levin <sashal@...nel.org>
>> > ---
>> > Documentation/admin-guide/security-bugs.rst | 21 +++++++++++++--------
>> > 1 file changed, 13 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/Documentation/admin-guide/security-bugs.rst b/Documentation/admin-guide/security-bugs.rst
>> > index dcd6c93c7aac..c62faced9256 100644
>> > --- a/Documentation/admin-guide/security-bugs.rst
>> > +++ b/Documentation/admin-guide/security-bugs.rst
>> > @@ -61,14 +61,19 @@ Coordination
>> >
>> > Fixes for sensitive bugs, such as those that might lead to privilege
>> > escalations, may need to be coordinated with the private
>> > -<linux-distros@...openwall.org> mailing list so that distribution vendors
>> > -are well prepared to issue a fixed kernel upon public disclosure of the
>> > -upstream fix. Distros will need some time to test the proposed patch and
>> > -will generally request at least a few days of embargo, and vendor update
>> > -publication prefers to happen Tuesday through Thursday. When appropriate,
>> > -the security team can assist with this coordination, or the reporter can
>> > -include linux-distros from the start. In this case, remember to prefix
>> > -the email Subject line with "[vs]" as described in the linux-distros wiki:
>> > +<linux-distros@...openwall.org> mailing list so that distribution vendors are
>> > +well prepared to issue a fixed kernel upon public disclosure of the upstream
>> > +fix. As a reporter, you must read and accept the list's policy as outlined in
>> > +the linux-distros wiki:
>> > +<https://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and-instructions-for-reporters>.
>> > +When you report a bug, you must also provide a tentative disclosure date and
>> > +time in your very first message to the list. Distros will need some time to
>> > +test the proposed patch so please allow at least a few days of embargo, and
>> > +vendor update publication prefers to happen Tuesday through Thursday. When
>> > +appropriate, the security team can assist with this coordination, or the
>> > +reporter can include linux-distros from the start. In this case, remember to
>> > +prefix the email Subject line with "[vs]" as described in the linux-distros
>> > +wiki:
>> > <http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists>
>>
>> Do we really need to describe all of the information on how to use the
>> distro list here? That's why we included the link, as it has all of
>> this well spelled out and described. If anything, I would say we should
>> say less in this document about what linux-distros do, as that is
>> independent of the Linux security team.
>
>Agreed, and it also means that any changes linux-distros make to their
>policy won't be reflecting in the numerous kernel trees out there, so a
>link is much better imo.
I agree that the 2nd part about embargo timelines is redundant, but I
only addressed it because the document was already addressing embargos.
I only now realized that the link we had there was just going to the
main wiki page by mistake: the tag it was trying to point to was removed
from the wiki page. We should probably update that too.
With regards to the explicit instruction to agree with policies, I think
we do need it there. Right now this section reads as "for embargoes work
with linux-distros@...openwall.org, and btw they have a wiki which you
may or may not need to read".
We probably do need to stress here that linux-distros has different
policies than security@...nel.org.
--
Thanks,
Sasha
Powered by blists - more mailing lists