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