Re: linux-distros list policy and Linux kernel

[Seth Arnold <seth.arnold () canonical com>]

On Mon, May 16, 2022 at 03:12:20PM +0200, Jason A. Donenfeld wrote:
> So I think a lot of the kernel's commit message obfuscation and unusual
> disclosure ideas stem from a sort of collective sigh and desire not to
> join the circus of security performers. They'll commit the fix, because

I have seen some kernel developers say that the "security bugs" that
get attention are no different from dozens of other bugfixes that are
committed to the kernel every cycle.

If I've understood the complaint correctly they feel like we, the security
community, are engaging in a dog-and-pony show around ten percent of the
actual problems in the kernel. The other ninety percent get obfuscated
commit messages and no one makes a fuss, because it's just way easier
that way.

I suspect there's some truth to it.

(We get hyperbolic reports from security researchers with proof-of-concept
exploits that are basically syzkaller reproducers and while they look
like they're real issues, it's hard to get excited when it's just .1%
of syzkaller's findings.)

Is this how the wider kernel community sees the various downstream
security efforts?

If this accurately describes feelings held by Linux developers, perhaps we
need larger changes. Ubuntu has (far too many) kernel trees and the only
way we can keep track of the CVEs is via our break-fix lines that show
when issues were introduced and when they were fixed. The Fixes: lines in
commit messages are wonderful assistances here.

Given how much effort it takes me to assign CVEs for kernel issues, I've
wondered before if we (me, us, the community as a whole, etc) ought to
have a very standard and lightweight way to publish kernel CVEs, something
that's not much more than the Fixes: lines already in the commits.

I know this discussion didn't start around assigning CVEs to kernel
issues, but if we're missing more than we're handling, perhaps it ought to
be part of the discussion.

Thanks

Attachment: signature.asc
Description: