oss-security - Re: linux-distros list policy and Linux kernel, again

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230826023129.GA2930052@millbarge>
Date: Sat, 26 Aug 2023 02:31:29 +0000
From: Seth Arnold <seth.arnold@...onical.com>
To: oss-security@...ts.openwall.com
Subject: Re: linux-distros list policy and Linux kernel, again

On Sat, Aug 26, 2023 at 12:23:59AM +0200, Solar Designer wrote:
> I'd appreciate any well-reasoned votes and constructive suggestions.
> Maybe there are good ideas that didn't cross my mind yet.

I think we'd all be better served to wait until next year before we try to
make changes. Some additional space would probably do everyone some good.

For my own part, I was frustrated getting a dozen emails about the policy
and deadlines and folks saying "we don't even have a fix yet please back
off" etc over and over and over again. There were usually more emails
about the policy than about the issue. I can't speak for the others but
perhaps if we, as a group, were less vocal about the policies on every
single bug report it might have been easier to work together.

For every security issue in the kernel that gets a CVE and The Whole
Process, I'm sure there's five or ten more that go unnoticed by the
wider world. Trying to do The Security Process on the ones that come to
light feels silly when there's far more issues that may allow privilege
escalation that never get the theater treatment. While we can (and should)
try to bring more of these to light we might also reduce the friction on
the ones that do come to light.

I was also annoyed with the endless stream of "I found a security bug in
the kernel, give me a CVE!" that are a mangled syzkaller reproducer and
no work to diagnose the problem or propose a patch. If every syzkaller
issue received a CVE automatically, we'd immediately remove the most
noisome posts.

Here's what I think would help the most, if we in the future try to get
copied on reports "like the old days":

- No replies from distros@ subscribers about list policies. None. distros@
  subscribers can and should feel free to engage about the bug, about
  testing, about concerns, etc. But none about the list policies.

  We all know that the kernel developers don't just sit on reports for
  six months before they're forced to take action by public posts. They
  want fixes in a timely fashion and they're doing the work to deliver
  fixes in a timely fashion.

  They publish their patches in public very soon after the work is
  complete which addresses your concern about the inboxes and mail
  servers being a jackpot of private vulnerabilities.

  We shouldn't harangue them about the policies.

- Make it clear to all that distributions can apply fixes to their kernels
  as soon as patches are in publicly visible trees or mail lists. Trying
  to coordinate dates didn't work well: The kernel people don't want
  to hold off on publishing fixes for an arbitrary reason. The distro
  people have their own cycles for integrating patches, performing quality
  control, preferences to not publish updates on important holidays or
  weekends, etc.

  Let's just let the kernel developers work on fixes on their own schedule
  and whenever they go public, just go with it.

  We shouldn't try to coordinate dates.

- Ask Red Hat's CNA to consider setting up an automatic CVE assignment
  process for syzkaller issues. (Red Hat's CNA is now serving as a Root
  CNA for FOSS issues in general, so it feels like a plausible place to
  put this process. Google runs syzkaller and has four CNAs, perhaps
  one of them would be a better fit. Maybe the Linux Foundation could
  run a CNA for this purpose. I'm not picky.)

  We shouldn't indulge the very-low-effort-researchers who aren't putting
  in much effort but trying to get CVEs.

Thanks

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.