[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.