you *still* don't understand what i was saying. for the Nth time: i am *not* talking about
commits lacking security impact information when it is *not* known at the time of the commit
(although one would think that in this age at least a few exploitable bug classes should be
known to kernel developers and be recognized and thus documented as such in the commit).
what i *am* talking about is commits where the security impact is already *known* yet the
commit very deliberately does *not* mention it or tries to downplay it as much as possible.
you want proof? the last one i mentioned, look at
https://bugzilla.redhat.com/show_bug.cgi?id=194215#c0 in the Red Hat bugzilla. the actual
author of that one was not Marcel Holtmann but Paul Mackerras himself. the problem? Marcel did
not quote the full email, he omitted one of the last paragraphs, as you will see below, for a
good reason (good for him and other kernel devs trying to evade full disclosure, something
they supposedly support, at least when it's for PR purposes, that is):
I'd appreciate advice about the best way forward here, and to what
degree we should be candid about the reason for the patch in the
commit message when it gets committed to Linus' git repository.
and candid it became indeed. if you want more juicy stuff, go ask your supposedly honest
kernel devs for the kernel security list archives.
PS: i hope you're not a kernel contributor, you certainly haven't got a clue about what
belongs into a commit message. you also don't have a clue about what bugs have a security
impact, it's most certainly not *most bugs*. but i understand, what i've been saying sounds
unbelievable to you, so it's easier to attack the messenger, instead of actually checking out
the situation for yourself.