Kernel.org's road to recovery

they're not. 'program carefully' is as useful as 'live healthily'. useless information by itself, the devil's in the details.

> Finding out if some random mistake you notice and fix has security
> implications is extra, non-productive work.

and you keep bringing up this strawman because...? noone asked kernel devs to do the assessment themselves, what they're being asked is to pass down that info if someone else did it for them (and their users).

> If you track down some reported bug, your fix will presumably refer to
> the report (with PoC and security assessment).

what i'd send out would most definitely have this information *but* it would then be *censored* in the actual commit message. i'll refer you to Linus's statement i linked somewhere above.

> In no case are commit comments altered.

they are, and not only for covering up security fixes. Linus routinely adds his own blurb to commits where he thinks something's missing (look for "- Linus" in the commit message).

> And I'm convinced that the bugs with known by the commiter only security
> implications being fixed is a vanishingly small minority.

and how would you know that a given commit's security impact was known by the committer if that information is covered up? could that suppression of information be the cause of the bias in your beliefs perhaps?

> Adding comments detailing how a signedness mistake or a possible
> wraparound could led to a buffer overflow or other problems later on is
> pure noise.

depends on what you understand as 'details' in the above. personally i'd already be happy if only the words 'integer wraparoud' or 'buffer overflow' appeared in the commit (and i don't care about the 'how to exploit this'), but even *they* are covered up (i'll refer you again to Linus's assertion that 'no greppable keywords'). looks like you've just proved how much you personally value such information ;).