Message-Id: <20230305220010.20895-3-vegard.nossum@oracle.com>
Date:   Sun,  5 Mar 2023 23:00:05 +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 2/7] Documentation/security-bugs: misc. improvements

This mostly just clarifies things and moves a few things around in
preparation for the subsequent changes.

Most notably, pull the "security@...nel.org" address up into the first
paragraph as this the most vital piece of information in the whole
document.

Also fix a few markup issues.

Signed-off-by: Vegard Nossum <vegard.nossum@...cle.com>
---
 Documentation/process/security-bugs.rst | 37 ++++++++++++++-----------
 1 file changed, 21 insertions(+), 16 deletions(-)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 82e29837d589..f1326d4e9718 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -1,36 +1,41 @@
 .. _securitybugs:
 
-Security bugs
-=============
+Reporting security bugs
+=======================
 
 Linux kernel developers take security very seriously.  As such, we'd
 like to know when a security bug is found so that it can be fixed and
 disclosed as quickly as possible.  Please report security bugs to the
-Linux kernel security team.
+Linux kernel security team at security@...nel.org, henceforth
+"the security list".  This is a closed list of trusted developers who
+will help verify the bug report and develop a patch in case none was
+already proposed.
 
-Contact
--------
+While the security list is closed, the security team may bring in extra
+help from the relevant maintainers to understand and fix the security
+vulnerability.
 
-The Linux kernel security team can be contacted by email at
-<security@...nel.org>.  This is a private list of security officers
-who will help verify the bug report and develop and release a fix.
-If you already have a fix, please include it with your report, as
-that can speed up the process considerably.  It is possible that the
-security team will bring in extra help from area maintainers to
-understand and fix the security vulnerability.
+Note that the main interest of the kernel security list is in getting
+bugs fixed and getting patches reviewed, tested, and merged; CVE
+assignment, disclosure to distributions, and public disclosure happen on
+different lists with different people.
+
+Contacting the security list
+----------------------------
 
 As it is with any bug, the more information provided the easier it
 will be to diagnose and fix.  Please review the procedure outlined in
-'Documentation/admin-guide/reporting-issues.rst' if you are unclear about what
+Documentation/admin-guide/reporting-issues.rst if you are unclear about what
 information is helpful.  Any exploit code is very helpful and will not
 be released without consent from the reporter unless it has already been
-made public.
+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
-:doc:`regular patch submission <../process/submitting-patches>`
-(even if you don't have a patch yet): describe the problem and impact, list
+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 and embargoed information
-- 
2.40.0.rc1.2.gd15644fe02

Powered by blists - more mailing lists