Documentation: insist on the plain-text requirement for security reports

As the trend of AI-generated reports is growing, the trend of unreadable
reports in gimmicky formats is following, and we cannot request that
developers rely on online viewers to be able to read a security report
full for formatting tags. Let's just insist on the plain text requirement
a bit more.

Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20251129141741.19046-1-w@1wt.eu>

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 84657e7d2e5b4be391baf2c2d6c96959aed5389e..c0cf93e11565e2ff693a259a82c7d2ef7b690c66 100644 (file)
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -33,12 +33,16 @@ 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.
 
-Please send plain text emails without attachments where possible.
+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.
+Markdown, HTML and RST formatted reports are particularly frowned upon since
+they're quite hard to read for humans and encourage to use dedicated viewers,
+sometimes online, which by definition is not acceptable for a confidential
+security report.
 
 Disclosure and embargoed information
 ------------------------------------