Many reports still come with zip files or other archives attached, which
are a pain to deal with, may be blocked by filtering on some maintainers'
end, and that also encourage recipients to adopt risky practices of
opening binary files. The doc only used to say to avoid attachments
"where possible".
Let's clarify that archives, binary files and documents are never
acceptable, that large reproducers should be attached as plain text
source files, and that scripts generating the required files (e.g. file
system images) are a better solution.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index e0fb7058a999e..ac4409d3b27b2 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -306,7 +306,11 @@ at once by the same commit, then it may be acceptable to report them at once.
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
+issue if all the details are hidden away in attachments. Archives (zip, tar,
+etc.), binary files and documents (PDF, etc.) are never acceptable: when a
+reproducer is too large to be placed in the message, attach its source files
+as plain text, and provide scripts that generate the required files (e.g. file
+system images) instead of the files themselves. 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, and
list reproduction steps, all in plain text, then provide a proposed fix as
--
2.52.0