This mostly just clarifies things and moves a few things around in preparation for the subsequent changes. Most notably, pull the "security@xxxxxxxxxx" 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@xxxxxxxxxx> --- 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@xxxxxxxxxx, 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@xxxxxxxxxx>. 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
