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