Quotes of the week

[Posted July 4, 2012 by corbet]

Please find large crayon and write on forehead "when fixing a bug, be sure to describe the end-user impact of that bug".

— Andrew Morton

Fundamentally, 8k stacks on x86-64 are too small for our increasingly complex storage layers and the 100+ function deep call chains that occur.

— Dave Chinner

Quotes of the week

Posted Jul 5, 2012 9:01 UTC (Thu) by PaXTeam (guest, #24616) [Link] (3 responses)

the full(er) quote:

> "when fixing a bug, be sure to describe the end-user impact of that bug".
> Then others will have a chance of deciding whether the fix should be backported.

so does security impact end-users? one of these days kernel devs should really make up their mind.

Quotes of the week

Posted Jul 5, 2012 10:26 UTC (Thu) by liljencrantz (guest, #28458) [Link] (1 responses)

It is my understanding that information on security issues is handled through different channels, and as such back ports should reliably happen for security patches when appropriate. That doesn't mean the current security policy is the best one, but at least it should not *systematically* drop security patches.

Also please not that the kernel community is not a uniform hive mind, I can't remember reading any posts from Andrew Morton specifically in favor of the "Obfuscate commit messages for security patches"-policy.

Quotes of the week

Posted Jul 7, 2012 9:15 UTC (Sat) by PaXTeam (guest, #24616) [Link]

> It is my understanding that information on security issues is handled
> through different channels, and as such back ports should reliably
> happen for security patches when appropriate.

what are these 'different channels' and why would they ensure reliable backports of security fixes? and doesn't this contradict the 'bugs are just bugs' mantra? ;)

> That doesn't mean the current security policy is the best one, but at
> least it should not *systematically* drop security patches.

as for what's (not) getting *systematically* dropped, look at the fixes that spender backports into grsecurity, *systematically*. calling the 'current security policy' as not the best one is quite an understatement.

> [..]I can't remember reading any posts from Andrew Morton specifically
> in favor of the "Obfuscate commit messages for security patches"-policy.

that's because he didn't say anything, pro or contra. which is quite a shame because there're clearly signs that not everyone agrees with the current policy (just observe LWN's own article earlier this year) yet there're no discussions (in public) about it.

PS: the latest and greatest just in: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;...

'Hold a file reference in madvise_remove' is the what, not the why. at least the actual commit message contains a greppable keyword or two so everyone not otherwise paying attention knows what's just happened again (even though use-after-free is a far cry from 'exploitable by unprivileged users', something that should have been mentioned per Andrew's complaint, and no, a CC to stable@ does not an explanation make). good show guys, keep ridiculing yourselves.

Quotes of the week

Posted Jul 10, 2012 6:14 UTC (Tue) by malor (guest, #2973) [Link]

Hah, I was going to make a similar comment.

Only write it in crayon unless it's security related, and might actually HURT someone. If your bug means that someone could get hacked -- which, in the era of governments actively cyberattacking their own citizens, means they could be arrested and tortured and/or executed -- well, in that case, of course you should hide it. The last thing they need to know is that using your software could kill them.

But, as long as the bug isn't *serious*, then, yeah, write it in crayon. You can pretend to be honest, without having to deal with that pesky embarrassment stuff.