Quotes of the week [LWN.net]

Quotes of the week

Posted Jul 5, 2012 10:26 UTC (Thu) by liljencrantz (subscriber, #28458)
In reply to: Quotes of the week by PaXTeam
Parent article: Quotes of the week

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.

(Log in to post comments)

Quotes of the week

Posted Jul 7, 2012 9:15 UTC (Sat) by PaXTeam (subscriber, #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.