Re: [MAINTAINERS SUMMIT] Scaling our security process

On Fri, Jul 17, 2026 at 06:59:26AM +0200, Greg KH wrote:
> > > > 1. Does security@ still work? It was built for a handful of carefully written
> > > > reports, handled start to finish by a small group of volunteers. That process
> > > > never really scaled before, and it won't scale now. Does it make sense to
> > > > separate the roles? let AI driven tooling handle intake, filtering, and
> > > > reproduction, and keep the humans for developing and coordinating fixes for
> > > > reports that survive triage?
> > > 
> > > It was not really "built" for anything other than a place that people
> > > could report security bugs and get them fixed.  We have changed the way
> > > it works over the past months, and for right now, things seem _MUCH_
> > > smoother than ever before.
> > > 
> > > Also, we are getting funding "any day now" to have someone work full
> > > time on this, to be the "point person" for the alias to help when things
> > > fall through the cracks, as sometimes happens.  We have verbal
> > > guarantees of at least 6 months funding, and if that goes well, it
> > > should be extended.
> > 
> > It almost sounds like we need a CRM system here rather than a person?
> 
> Hah, no, any single-point-of-failure here would not be a good thing.

I agree, and I'm actually concerned that [email protected] is a SPOF as
well. If someone is sitting on a bad enough 0-day vulnerability, we have to
assume that they will be able to compromise kernel.org and knock us offline
(or, more sneakily, control what [email protected] receives and doesn't).

I've played with the idea of several SecureDrop servers that sit behind
OnionBalance and can receive security reports, but I'm not sure if this is
going too deep down the over-complicating-it rabbit hole.

An easier solution may be:

- publish a security.txt that lists multiple addresses that are known to live
  on disparate mail hosting infrastructure, in addition to [email protected]
  (e.g. Greg KH, James B, Linus T); this way a security report is more assured
  to be delivered to at least one of them and not gated on kernel.org being up
  and reliable
- make sure members of the security team are using their direct delivery
  addresses instead of kernel.org aliases
- set up a secure parallel back-channel mechanism to be used when email is
  being disrupted (e.g. a Signal group)

I still think a SecureDrop server may be useful for anonymous security
reports, but this is a separate consideration.

-K