[eqvinox]

> If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong.

Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug".

"Every bug is a security bug" means "we fix things when they need fixing, categorizing the fixes is not our job and you'll need to do that yourself".

As such, the current new approach is in fact a concession, there's now a broad pre-categorizing of fixes you can work off.

> making people not so familiar with the codebase (as the maintainers) do triage

You seem to be under the impression that you hadn't needed to do that before. Which, to be fair, worked for a long time. From an engineering perspective this was always a case of "skipping inspections and verification", because the Linux community never agreed to do that work on top of providing the system.

> I hope they get burnt quick by this approach.

How would they get burnt by this? Social pressure from other kernel developers (or even outside) isn't going to have that effect. The only possible influence would be from employers paying for Linux work — in which case it's a perfectly reasonable discussion about spending paid time on security issues.

[Avamander]

> Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug".

Then instead of this, don't? It's utterly childish.

> How would they get burnt by this? Social pressure from other kernel developers (or even outside) isn't going to have that effect.

Fewer organisations willing to cooperate with them, for one? Social pressure comes in many forms and shapes, there's no way it won't have any effect.

> The only possible influence would be from employers paying for Linux work

They're going to be paying someone else to provide a clean feed instead of the organization that deliberately hinders these efforts.

[eqvinox]

> They're going to be paying someone else […]

And that's perfectly fine, it's open source software. Either way someone gets paid to look at the patches, which is my point.

If you want to do it in a cost-effective manner, you'll find other people with the same requirements, since the work result is "shareable".

> […] instead of the organization that deliberately hinders these efforts.

There is no such organization, and it feels like you have very little understanding of the organizational (and funding) structures behind the Linux kernel. I really can't extend my comments into a full-blown explanation of this, sorry.

(No, the Linux Foundation does not perform the role you're implying: they don't currently and likely never will sell a "clean feed".)

> Fewer organisations willing to cooperate with them[…]

I have no data on this but it is entirely reasonable (and I believe it likely) that the current behavior was requested (or encouraged) of involved organisations and people by cooperating organisations and people.

[Avamander]

I think you got a bit confused.

> There is no such organization

There is such an organization, the Linux Foundation is the CNA being the hindrance to these efforts. And yes, they won't perform the role, someone else will and they will be paid for it.

For some that's fine, I find it a significant amount of wasted effort, confusion and potential issues.

[eqvinox]

>> They're going to be paying someone else to provide a clean feed instead of the organization that deliberately hinders these efforts.

You were implying the Linux Foundation is attempting to get paid for providing said "clean feed".

Anyway, this has devolved far enough.

[Ed.: the Linux Foundation isn't even the CNA, shame on me for accepting that without verifying. The actual CNA is kernel.org. https://www.cve.org/Media/News/item/news/2024/02/13/kernel-o... ]