Re: [PATCH] Documentation/security-bugs: provide more information about linux-distros

[Sasha Levin]

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@xxxxxxxxxxxx>
> > > Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
> > > ---
> > >  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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx, 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@xxxxxxxxxxx

--
Thanks,
Sasha