[gregkh]

And what would that "middle ground" look like?

With the current rate of change that the kernel community develops at, including the patches backported to the stable/longterm kernels, it's impossible to try to evaluate each and every patch for "is this something that could be exploited or not?"

Companies have tried, it was fun watching them, but they quickly gave up and declared it impossible and much safer to just take all stable patch updates instead.

I've also talked to MITRE about just applying for a CVE for ever stable kernel patch (20+ a day), and while they appreciated me not doing that, they agreed that the current model of CVEs just does not work at all for the Linux kernel and that what we are doing is fine.

See my Kernel Recipes talk last year for details about all of that if you are curious.

[despera]

I understand that completely and i already know your thoughts on that and in some extend i do agree.

Still, i think we do have in hand a very characteristic issue that even without knowing the details, simply by searching commit messages for "crypto" "key" "buffer" etc it should alert somebody to give it a second and third look.

[eqvinox]

Hell no. You can't just "guess by words."

The only thing (far!) worse than no impact marking is incomplete impact marking. That's just giving people a way to cop out, and they WILL use it.

[despera]

How is no marking better than some marking?

If there is a commit that refers to a "memory leak" why shouldn't be, at least superfluously, checked, identified and have distros informed? (e.g 2ca068be09bf8e285036603823696140026dcbe7)

If the crypto fix was assigned early as a vulnerability would have stayed unpatched for that long?

[eqvinox]

> How is no marking better than some marking?

With no marking it is clear what it means: commits have not been audited to identify security-relevant ones.

With partial, incomplete marking, unmarked commits can be one of two things: commits that have not been looked at, and commits that have been looked at and are believed to contain no security relevant changes.

The majority of commits will be in the "not looked at" category. And there's enough people around to have a significant subset of them be lazy, ignorant, unskilled or stupid and take that as "contains no security relevant changes."

P.S.: also, patches are already marked. By being included in the LTS series. Because that means they were important enough to get a backport — though not necessarily due to security impact.

[despera]

I do agree with the premises, i don't agree with your conclusion.

Yes only a part of patches would be marked as such. That, major or minor, part would simply mean that people won't have to reinvent the particular wheel, as happened in this case. People won't be missing critical _discovered_ changes, the vulnerability would be discussed, recognized in its totality (PoC, documentation etc) and proper patches will be offered. There have been cases where LTS backports were old revisions of bad patches.

I think that baking LTS kernels is unnecessarily closer to an artistic approach of doing things.