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@xxxxxxxxxx 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@xxxxxx/ Link: https://lore.kernel.org/all/20220607090726.GB32282@willie-the-truck/ Cc: Willy Tarreau <w@xxxxxx> Cc: Will Deacon <will@xxxxxxxxxx> Signed-off-by: Vegard Nossum <vegard.nossum@xxxxxxxxxx> --- 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
