mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Jonathan Corbet <corbet@lwn.net>
Cc: skhan@linuxfoundation.org, Randy Dunlap <rdunlap@infradead.org>,
	workflows@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	gregkh@linuxfoundation.org,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>
Subject: [PATCH 11/14] docs: security-bugs: explain why directly sent reports add extra work
Date: Mon,  9 Nov 2026 09:02:37 +0100	[thread overview]
Message-ID: <20261109080240.29444-12-w@1wt.eu> (raw)
In-Reply-To: <20261109080240.29444-1-w@1wt.eu>

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


  parent reply	other threads:[~2026-11-09  8:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  8:02 [PATCH 00/14] security-bugs doc updates Willy Tarreau
2026-11-09  8:02 ` [PATCH 01/14] docs: security-bugs: reorganize the document without changing its contents Willy Tarreau
2026-11-09  8:02 ` [PATCH 02/14] docs: security-bugs: clarify when to Cc the security team Willy Tarreau
2026-11-09  8:02 ` [PATCH 03/14] docs: security-bugs: never publish reproducers of bugs with a security impact Willy Tarreau
2026-11-09  8:02 ` [PATCH 04/14] docs: threat-model: clarify the case of automatically mounted file systems Willy Tarreau
2026-11-09  8:02 ` [PATCH 05/14] docs: security-bugs: explain how to send a fix that can be applied Willy Tarreau
2026-11-09  8:02 ` [PATCH 06/14] docs: security-bugs: do not send archives or binary attachments Willy Tarreau
2026-11-09  8:02 ` [PATCH 07/14] docs: security-bugs: first-time reporters must send a single report first Willy Tarreau
2026-11-09  8:02 ` [PATCH 08/14] docs: security-bugs: explain what to do when a report gets no response Willy Tarreau
2026-11-09  8:02 ` [PATCH 09/14] docs: security-bugs: reports left unanswered for 7 days will be dropped Willy Tarreau
2026-11-09  8:02 ` [PATCH 10/14] docs: security-bugs: add a section for maintainers receiving reports Willy Tarreau
2026-11-09  8:02 ` Willy Tarreau [this message]
2026-11-09  8:02 ` [PATCH 12/14] docs: security-bugs: explain why AI-found bugs are handled publicly Willy Tarreau
2026-11-09  8:02 ` [PATCH 13/14] docs: submitting-patches: defer to security-bugs.rst for security fixes Willy Tarreau
2026-11-09  8:02 ` [PATCH 14/14] docs: netdev: align the security fixes section with security-bugs.rst Willy Tarreau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261109080240.29444-12-w@1wt.eu \
    --to=w@1wt.eu \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=skhan@linuxfoundation.org \
    --cc=workflows@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®