[PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI

Willy Tarreau posted 3 patches 1 month ago
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
[PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI
Posted by Willy Tarreau 1 month ago
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
Re: [PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI
Posted by Jonathan Corbet 1 month ago
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
Re: [PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI
Posted by Willy Tarreau 1 month ago
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
Re: [PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI
Posted by Leon Romanovsky 1 month ago
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.
Re: [PATCH v3 0/3] Documentation: security-bugs: new updates covering triage and AI
Posted by Willy Tarreau 1 month ago
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