[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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)
Powered by blists - more mailing lists
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.
