[v3,2/7] Documentation/security-bugs: misc. improvements

Message ID 20230305220010.20895-3-vegard.nossum@oracle.com
State New
Headers
Series Documentation/security-bugs: overhaul |

Commit Message

Vegard Nossum March 5, 2023, 10 p.m. UTC
  This mostly just clarifies things and moves a few things around in
preparation for the subsequent changes.

Most notably, pull the "security@kernel.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@oracle.com>
---
 Documentation/process/security-bugs.rst | 37 ++++++++++++++-----------
 1 file changed, 21 insertions(+), 16 deletions(-)
  

Comments

Greg KH March 12, 2023, 3:06 p.m. UTC | #1
On Sun, Mar 05, 2023 at 11:00:05PM +0100, Vegard Nossum wrote:
> This mostly just clarifies things and moves a few things around in
> preparation for the subsequent changes.
> 
> Most notably, pull the "security@kernel.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.

When you have "also" in a patch changelog, that usually means this
should be a separate patch.  Can you just fix up the markup issues first
please?

Also, a few minor comments below:

> 
> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.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@kernel.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@kernel.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

It's not "main interest", it is the "only task" of it.  That's all the
list does, nothing else.

> +assignment, disclosure to distributions, and public disclosure happen on
> +different lists with different people.

How about this rephrasing:

	The only tasks of the kernel security list are to triage
	reported potential security bugs, generate and test a fix, and
	get the fix merged into Linus's and the stable kernel trees.
	The security list does not deal with CVE assignment or any sort
	of disclosure at all.

thanks,

greg k-h
  

Patch

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@kernel.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@kernel.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