Many reporters imagine that contacting a maintainer directly will bring
their report a special attention but it's exactly the opposite because
it breaks the normal workflow, and deprives the maintainer from their
usual tools (CI, reviews etc), and even requires extra care (e.g. use
separate branches, avoid CCing stable etc). Let's just explain this
upfront so that reporters understand that there is a reason for everyone
insisting on public posts.
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/process/security-bugs.rst | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 280f7f3a94603..69dbc47f54625 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -15,7 +15,14 @@ It is important that most bugs are handled publicly so as to involve the widest
possible audience and find the best solution. By nature, bugs that are handled
in closed discussions between a small set of participants are less likely to
produce the best possible fix (e.g., risk of missing valid use cases, limited
-testing abilities).
+testing abilities). In addition, dealing with private discussions on patches
+adds much more burden to maintainers who cannot follow their usual process nor
+benefit from their usual tools. For example, many subsystems have CI jobs
+running on publicly posted patches and will not merge a fix before it has been
+validated, and automated review tools such as Sashiko review patches posted to
+the lists. Since the fix will have to be posted publicly anyway, sending it
+privately first only delays it by the time needed to ask for it to be reposted
+publicly, adds extra work, and loses the benefit of early reviews.
It turns out that the majority of the bugs reported via the security team are
just regular bugs that have been improperly qualified as security bugs due to
--
2.52.0