| |||||||||||||
Stable kernel 2.6.32.8Stable kernel 2.6.32.8Posted Feb 10, 2010 4:42 UTC (Wed) by spender (subscriber, #23067)In reply to: Stable kernel 2.6.32.8 by njs Parent article: Stable kernel 2.6.32.8
It was the plural 'you', referring in general to those who agree with that completely misguided notion, and in doing so enable it to continue to be official policy.
-Brad
(Log in to post comments)
Stable kernel 2.6.32.8 Posted Feb 10, 2010 8:53 UTC (Wed) by chad.netzer (✭ supporter ✭, #4257) [Link]
For those wanting more context:
http://kerneltrap.org/Linux/Security_Bugs_and_Full_Disclo...
I personally think Linus's position is more compelling:
Stable kernel 2.6.32.8 Posted Feb 10, 2010 21:07 UTC (Wed) by ballombe (subscriber, #9523) [Link]
Yes, but note that the situation of the stable kernel team is different from Linus situation.
Linus argues that for most patches, it is unknown whether it fixes a security issue, and so it is misleading to mark a small subset of them as 'security fix', and that cherry-picking patches marked 'security fix' create a false sense of security.
However, the stable kernel team job is precisely to cherry-pick patches, and it can be expected that some of them have been picked because they fix a security issue.
Stable kernel 2.6.32.8 Posted Feb 11, 2010 8:00 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257) [Link]
Surely it is an issue of style and not substance, is it not? If a bugfix is later
shown to be a security fix as well, should it be rewritten to indicate it as such, or is it not easier to just track this elsewhere where commits can be unambiguously referred to? If the issue is that security fixes and commits aren't being disseminated or discussed, surely that can be addressed outside of commit messages.
Stable kernel 2.6.32.8 Posted Feb 11, 2010 10:16 UTC (Thu) by nix (subscriber, #2304) [Link]
Rewriting commit messages once they land in the stable kernel tree (as opposed to the stable patch queue) is not possible: you'd break everyone pulling the stable tree.
Stable kernel 2.6.32.8 Posted Feb 11, 2010 18:13 UTC (Thu) by chad.netzer (✭ supporter ✭, #4257) [Link]
Right. Which is another reason *not* to tie any security analysis to a commit message, since the known security impact of a commit can change.
Stable kernel 2.6.32.8 Posted Feb 12, 2010 0:03 UTC (Fri) by nix (subscriber, #2304) [Link]
Well, sort of. It's a reason never to say 'this has no security impact',
but attacks only get worse, never better: it's safe to say 'this is a security hole', because it's not going to *stop* being a security hole.
|
|||||||||||||