[gregkh]

I've described how we (the kernel security team) handles this type of things many times, and even summarized it in the past here: http://www.kroah.com/log/blog/2018/02/05/linux-kernel-releas... Scroll down to the section entitled "Security" for the details.

If you wish to disagree with how we handle all of this, wonderful, we will be glad to discuss it on the mailing lists. Just don't try to rehash all the same old arguments again, as that's not going to work at all.

Also, this was fixed in a public kernel last week, what prevented you from updating your kernel already? Did you need more time to test the last release?

Edit: It was fixed in a public release 12 days ago.

[staticassertion]

I'm well aware of your policy. Yes, I disagree. Also, mailing lists suck and I'll continue to comment wherever I please about the matter.

> Just don't try to rehash all the same old arguments again, as that's not going to work at all.

No shit. People have been trying to explain all of this to you for decades lol I'm not stupid enough to think I'll succeed where they've failed.

[wtarreau]

I don't know what you don't understand: EVERY single kernel fixes a few vulnerabilities. If you lazily refuse to update because none of those say "hint: there is a vulnerability here", then you are taking the deliberate action of skipping some security fixes. Greg's announces always say "all users must upgrade". If there was sometimes a different signal such as "all users must really really really upgrade", then for sure you would simply skip all other ones, as it already seems like you're waiting for a lot of noise before deciding to apply due fixes, and you would remain vulnerable to plenty of other vulns for much longer.

Here the goal was to make sure that all those who correctly do their job are fixed in time. And they were. Those who blatantly ignore fixes... there's nothing that can be done for them.

[staticassertion]

So you update your kernel for every single commit as soon as it's merged in? If not, you already obviously understand how ridiculous your argument is.

I've already explained that most people have some sort of cadence for updating.

Based on your other comments you're just going to ignorantly parrot Greg's talking points. I don't think you have much insight into this.

[max_k]

> I don't think you have much insight into this.

I don't think you know who wtarreau is.

[staticassertion]

I obviously am very comfortable disagreeing with people who work on the kernel or adjacent software. Working in those areas does not at all make them correct, or even informed, especially with regards to security.

[bombcar]

What’s amusing is a few years back there WAS a security bug so critical that they DID handle it in a special and strange way.

[gregkh]

Yes, and because of that, we created a new process for those types of issues (i.e. broken hardware problems that need more coordination.) That process is documented at https://www.kernel.org/doc/html/latest/process/embargoed-har... if you are curious.

It's been working semi-well, and gives us a way to deal with longer embargo times (like months instead of weeks and days), but it does not integrate well into the linux-distro-like way of working just yet, which is an issue that hopefully will be resolved sometime in the future if the linux-distro members wish it to be.

[metadat]

> When doing kernel releases, the Linux kernel community almost never declares specific changes as “security fixes”. This is due to the basic problem of the difficulty in determining if a bugfix is a security fix or not at the time of creation. Also, many bugfixes are only determined to be security related after much time has passed, so to keep users from getting a false sense of security by not taking patches, the kernel community strongly recommends always taking all bugfixes that are released.

> Linus summarized the reasoning behind this behavior in an email to the Linux Kernel mailing list in 2008 ...

Since severity can be a moving target, it seems like there is no straightforward solution. With that said, by hiding the known ones, older distros don't have much of a hope in hell of getting all reported CVE fixes back-ported.

Why isn't there a public index mapping known CVE fixes to git commit IDs? This seems totally doable and would make the world a more secure place overall.

[NavinF]

> older distros don't have much of a hope in hell of getting all reported CVE fixes back-ported

Older distros have always had a ton of privilege escalation bugs and I don’t think that’s ever gonna change. If you can’t keep everything updated, your machines have to be single-tenant.

[staticassertion]

Greg would also discourage you from getting a CVE assigned at all, so you might be barking up the wrong tree.