Greg K-H

Serious question: Does that mean there's a chance Linux will do proper CVE, marking of releases, etc going forward? Last time I looked, it was still the fundamentally wrong "SeCuRiTy BuGs ArE lIkE aLl OtHeR bUgS" game.

At the Linux kernel level, yes, they still treat all bugs as potential security vulnerabilities. @gregkh can explain why better than I can.

I meant the inverse of Linus arguing that security fixes don't need to be marked specifically which makes downstream work and upgrades needlessly hard.

"downstream" only has to take the weekly stable/LTS releases to get all known security and bug fixes (i.e. security fixes we don't know about yet). How much easier can it get for them, we provide it all fully tested!

And if you want to know more about why CVEs are totally broken, especially for a project like the kernel, see my hour long talk: https://kernel-recipes.org/en/2019/talks/cves-are-dead-long-live-the-cve/ …

Given that upgrading is not always painless, knowing if a currently-used version is secure for a specific use case is still valuable as it can help defer non-essential upgrades. That being said, I will put your talk onto my backlog and honestly look forward to watching it.

Upgrading your kernel should _always_ be painless. Unless you depend on out-of-tree changes, and if so, well, that's your fault for trusting them, nothing the kernel community can do about them obviously.

The kernel itself, yes. I was referring to rebooting the system to run the new kernel. A lot easier now that most machines and services are cattle, but still. Also, just because it's painless does not mean everyone wants to upgrade immediately if everything's running nicely.