Message-Id: <20230305220010.20895-4-vegard.nossum@oracle.com>
Date:   Sun,  5 Mar 2023 23:00:06 +0100
From:   Vegard Nossum <vegard.nossum@...cle.com>
To:     Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
        Jiri Kosina <jkosina@...e.cz>,
        Solar Designer <solar@...nwall.com>,
        Will Deacon <will@...nel.org>, Willy Tarreau <w@....eu>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, Amit Shah <aams@...zon.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Laura Abbott <labbott@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Thorsten Leemhuis <linux@...mhuis.info>,
        Tyler Hicks <tyhicks@...ux.microsoft.com>,
        Vegard Nossum <vegard.nossum@...cle.com>
Subject: [PATCH v3 3/7] Documentation/security-bugs: improve security list section

Make this section about the security list easier to parse by:

1) reordering the content to make more sense,

2) adding "paragraph names" to make it visually easier to
   find exactly the information that you need for a given step (this
   will also be applied to the other sections for consistency in
   subsequent patches),

3) pulling some of the information that is relevant to contacting
   security@...nel.org specifically into the section about that list.

The remaining sections are about CVE assignment, coordinated
disclosure, etc., which are things the security list _doesn't_ deal
with. (These sections will be expanded and clarified in subsequent
patches.)

This patch is not meant to introduce any semantic changes, so in
case of a dispute the previous version will be authoritative.

Link: https://lore.kernel.org/all/20220601031254.GB26318@1wt.eu/
Link: https://lore.kernel.org/all/20220607090726.GB32282@willie-the-truck/
Cc: Willy Tarreau <w@....eu>
Cc: Will Deacon <will@...nel.org>
Signed-off-by: Vegard Nossum <vegard.nossum@...cle.com>
---
 Documentation/process/security-bugs.rst | 76 ++++++++++++-------------
 1 file changed, 35 insertions(+), 41 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index f1326d4e9718..fb156d146c42 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -31,42 +31,42 @@ be released without consent from the reporter unless it has already been
 made public.  Reporters are encouraged to propose patches, participate in the
 discussions of a fix, and test patches.
 
-Please send plain text emails without attachments where possible.
-It is much harder to have a context-quoted discussion about a complex
-issue if all the details are hidden away in attachments.  Think of it like a
-regular patch submission (see Documentation/process/submitting-patches.rst)
-even if you don't have a patch yet; describe the problem and impact, list
-reproduction steps, and follow it with a proposed fix, all in plain text.
+**Disclosure.** Once a robust patch or patchset has been developed, the
+release process starts.  The security list strongly prefers to have these
+posted for review and testing on public mailing lists and merged into the
+appropriate public git repository as soon as possible.  However, you or an
+affected party may request that the patch be withheld for some days; as a
+rule, the maximum is 7 calendar days.  An exceptional extension to 14
+calendar days is possible if it is agreed that the criticality of the bug
+requires more time.  The only valid reason for deferring the publication
+of a fix is to accomodate the logistics of QA and large scale rollouts
+which require release coordination.
+
+Please note that although a fix is public, there may still be value in
+withholding the details of its security relevance and/or how to exploit
+it for another while; see below for when and how to properly disclose
+the security impact of your findings publicly.
+
+**List rules.** Please send plain text emails without attachments where
+possible.  It is much harder to have a context-quoted discussion about a
+complex issue if all the details are hidden away in attachments.  Think
+of it like regular patch submission (see
+Documentation/process/submitting-patches.rst) even if you don't have a
+patch yet; describe the problem and impact, list reproduction steps, and
+follow it with a proposed fix, all in plain text.
+
+**Confidentiality.** While embargoed information may be shared with
+trusted individuals in order to develop a fix, such information will not
+be published alongside the fix or on any other disclosure channel
+without the permission of the reporter.  This includes but is not
+limited to the original bug report and followup discussions (if any),
+exploits, CVE information or the identity of the reporter.  All such
+other information submitted to the security list and any follow-up
+discussions of the report are treated confidentially even after the
+embargo has been lifted, in perpetuity.
 
-Disclosure and embargoed information
-------------------------------------
-
-The security list is not a disclosure channel.  For that, see Coordination
-below.
-
-Once a robust fix has been developed, the release process starts.  Fixes
-for publicly known bugs are released immediately.
-
-Although our preference is to release fixes for publicly undisclosed bugs
-as soon as they become available, this may be postponed at the request of
-the reporter or an affected party for up to 7 calendar days from the start
-of the release process, with an exceptional extension to 14 calendar days
-if it is agreed that the criticality of the bug requires more time.  The
-only valid reason for deferring the publication of a fix is to accommodate
-the logistics of QA and large scale rollouts which require release
-coordination.
-
-While embargoed information may be shared with trusted individuals in
-order to develop a fix, such information will not be published alongside
-the fix or on any other disclosure channel without the permission of the
-reporter.  This includes but is not limited to the original bug report
-and followup discussions (if any), exploits, CVE information or the
-identity of the reporter.
-
-In other words our only interest is in getting bugs fixed.  All other
-information submitted to the security list and any followup discussions
-of the report are treated confidentially even after the embargo has been
-lifted, in perpetuity.
+The Linux kernel security team is not a formal body and therefore unable
+to enter any non-disclosure agreements.
 
 Coordination
 ------------
@@ -93,9 +93,3 @@ assigned ahead of public disclosure, they will need to contact the private
 linux-distros list, described above. When such a CVE identifier is known
 before a patch is provided, it is desirable to mention it in the commit
 message if the reporter agrees.
-
-Non-disclosure agreements
--------------------------
-
-The Linux kernel security team is not a formal body and therefore unable
-to enter any non-disclosure agreements.
-- 
2.40.0.rc1.2.gd15644fe02

Powered by blists - more mailing lists