Hacker News new | ask | show | jobs
by despera 2181 days ago
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.
1 comments
eqvinox 2181 days ago
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.

link
despera 2181 days ago
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?

link
eqvinox 2181 days ago
> 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.

link
despera 2181 days ago
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.

link