Documentation/process/index.rst | 1 + Documentation/process/security-bugs.rst | 105 ++++++++++- Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++ 3 files changed, 340 insertions(+), 2 deletions(-) create mode 100644 Documentation/process/threat-model.rst
This series tries to translate recent discussions on the security list
on how to better handle reports. It details:
- when not to Cc: the security list
- what classes of bugs do not need to be handled privately
- minimum requirements for AI-assisted reports
As usual, this is probably perfectible but can already help in the short
term as we can point it to reporters, so barring any strong disagreement,
better continue to proceed in small incremental improvements and observe
the effects.
Thanks!
Willy
---
v3:
- comments about choice of words and option enumeration from Shuah
- AI is public, from Linus and Greg
- added extra reviewed-by (Greg, Shuah).
- Leon, I kept your reviewed-by since changes are very minimal and
didn't change the initial spirit.
v2:
- fixes for issues reported by Randy
- Greg's ack on the AI part
- reworded the "when to Cc" part based on Greg's feedback
(Greg I didn't take your original ack since the wording changed)
- split the threat model into its own document as per Greg's suggestion
---
Willy Tarreau (3):
Documentation: security-bugs: do not systematically Cc the security
team
Documentation: security-bugs: explain what is and is not a security
bug
Documentation: security-bugs: clarify requirements for AI-assisted
reports
Documentation/process/index.rst | 1 +
Documentation/process/security-bugs.rst | 105 ++++++++++-
Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++
3 files changed, 340 insertions(+), 2 deletions(-)
create mode 100644 Documentation/process/threat-model.rst
--
2.52.0
Willy Tarreau <w@1wt.eu> writes: > This series tries to translate recent discussions on the security list > on how to better handle reports. It details: > - when not to Cc: the security list > - what classes of bugs do not need to be handled privately > - minimum requirements for AI-assisted reports > > As usual, this is probably perfectible but can already help in the short > term as we can point it to reporters, so barring any strong disagreement, > better continue to proceed in small incremental improvements and observe > the effects. OK, I've applied the series to docs-fixes; after a short exposure in linux-next I'll ship it Linusward. I have a couple of comments on the individual changes that might merit an eventual add-on patch. Thanks, jon
On Tue, May 12, 2026 at 11:14:37AM -0600, Jonathan Corbet wrote: > Willy Tarreau <w@1wt.eu> writes: > > > This series tries to translate recent discussions on the security list > > on how to better handle reports. It details: > > - when not to Cc: the security list > > - what classes of bugs do not need to be handled privately > > - minimum requirements for AI-assisted reports > > > > As usual, this is probably perfectible but can already help in the short > > term as we can point it to reporters, so barring any strong disagreement, > > better continue to proceed in small incremental improvements and observe > > the effects. > > OK, I've applied the series to docs-fixes; after a short exposure in > linux-next I'll ship it Linusward. Thank you! > I have a couple of comments on the individual changes that might merit > an eventual add-on patch. Yes, feel free to suggest. I'm not fond of how the pub/priv decision is stretched into multiple sections and I'd like to rework it to have a dedicate section "public or private" which describes how to take the decision then later we can explain whom to contact depending on this choice. It's not much different from what we have but it would clarify certain points. So in any case I think I'll propose an update later, so anything you can propose to improve the situation is more than welcome! Thanks! Willy
On Sat, May 09, 2026 at 11:47:52AM +0200, Willy Tarreau wrote: > This series tries to translate recent discussions on the security list > on how to better handle reports. It details: > - when not to Cc: the security list > - what classes of bugs do not need to be handled privately > - minimum requirements for AI-assisted reports > > As usual, this is probably perfectible but can already help in the short > term as we can point it to reporters, so barring any strong disagreement, > better continue to proceed in small incremental improvements and observe > the effects. > > Thanks! > Willy <...> > - Leon, I kept your reviewed-by since changes are very minimal and > didn't change the initial spirit. Thanks. The intent is the same, and I'm not the right person to argue over the precise wording anyway.
On Sat, May 09, 2026 at 01:52:22PM +0300, Leon Romanovsky wrote: > On Sat, May 09, 2026 at 11:47:52AM +0200, Willy Tarreau wrote: > > This series tries to translate recent discussions on the security list > > on how to better handle reports. It details: > > - when not to Cc: the security list > > - what classes of bugs do not need to be handled privately > > - minimum requirements for AI-assisted reports > > > > As usual, this is probably perfectible but can already help in the short > > term as we can point it to reporters, so barring any strong disagreement, > > better continue to proceed in small incremental improvements and observe > > the effects. > > > > Thanks! > > Willy > > <...> > > > - Leon, I kept your reviewed-by since changes are very minimal and > > didn't change the initial spirit. > > Thanks. The intent is the same, and I'm not the right person to argue over > the precise wording anyway. That was also my understanding, but thanks for confirming! willy
© 2016 - 2026 Red Hat, Inc.