openkylin
/
linux
mirror of https://gitee.com/openkylin/linux.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity

Documentation/security-bugs: Explain why plain text is preferred 

The security contact list gets regular reports contained in archive
attachments. This tends to add some back-and-forth delay in dealing with
security reports since we have to ask for plain text, etc.

Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Jiri Kosina <jkosina@suse.cz>
Acked-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Acked-by: Will Deacon <will@kernel.org>
Acked-by: Willy Tarreau <w@1wt.eu>
Link: https://lore.kernel.org/r/202007091110.205DC6A9@keescook
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
This commit is contained in:
Kees Cook 2020-07-09 11:11:30 -07:00 committed by Jonathan Corbet
parent 0288199e1f
commit dbf35499fb
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
Documentation/admin-guide/security-bugs.rst
View File

@ -21,11 +21,18 @@ understand and fix the security vulnerability.
As it is with any bug, the more information provided the easier it 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 will be to diagnose and fix. Please review the procedure outlined in
admin-guide/reporting-bugs.rst if you are unclear about what :doc:`reporting-bugs` if you are unclear about what
information is helpful. Any exploit code is very helpful and will not information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been be released without consent from the reporter unless it has already been
made public. made public.
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
reproduction steps, and follow it with a proposed fix, all in plain text.
Disclosure and embargoed information Disclosure and embargoed information
------------------------------------ ------------------------------------