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 <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Message-ID: <[email protected]>

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
 ------------------------------------