Kernel.org's road to recovery

Posted Oct 9, 2011 15:22 UTC (Sun) by vonbrand (subscriber, #4458)
In reply to: Kernel.org's road to recovery by PaXTeam
Parent article: Kernel.org's road to recovery

If you look at any guidelines on secure programming, they are almost identical to "program carefully," only that they emphasize some points. Kernel programing is work that requires utmost care by its nature. Program with care, you should be in the clear. Finding out if some random mistake you notice and fix has security implications is extra, non-productive work.

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

In no case are commit comments altered. And I'm convinced that the bugs with known by the commiter only security implications being fixed is a vanishingly small minority. 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. The fix has to be applied regardless.

to post comments

Kernel.org's road to recovery

Posted Oct 10, 2011 8:54 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> If you look at any guidelines on secure programming, they are almost identical to "program carefully,"

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 ;).