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>
This commit is contained in:
Willy Tarreau 2025-11-29 15:17:41 +01:00 committed by Jonathan Corbet
parent 273aa250f1
commit ceddb2c001

View file

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