CIRCLE WITH A DOT

@joshbressers @gregkh @wdormann @Viss but I'd love to see someone trying, it would be an interesting grad research project I think.

@joshbressers @gregkh @wdormann @Viss and $0.02, security policies are pretty much our first line of defence for security issues for the GNU toolchain, where we try to identify clearly what constitutes a security issues. It also makes it clear to users how to use the tools and API securely. I don't think there's a reasonable equivalent for that for the kernel. One could try, but given that it's a privileged program that's involved in everything, it would be a largely pointless effort.

@joshbressers @gregkh @wdormann @Viss I'm not so sure, I just think there's a vast enough distance between the Linux kernel experience and pretty much any other project when it comes to security handling: volume, nature of reports, density of known exploitable issues. etc. that there aren't really any reasonable parallels to be drawn. I wouldn't think of throwing security policies, CVE evaluation or coordinated disclosure out because the kernel can't find a way to do it in a way that they like.

@joshbressers @gregkh @wdormann @Viss this may be true for the Linux kernel, especially with the resignation that the Linux CNA will assign a CVE for most reports, but it doesn't align with my anecdotal experience as glibc CNA. It's likely because we have significantly less volume (12 so far this year, with roughly twice as many reports) and we tend to be picky about what we assign to a CVE id to.

I'd argue that the kernel is special here and doesn't represent the ecosystem.