you should check out the last few -stable releases then and see how
the announcement doesn't ever mention the word 'security' while fixing
security bugs (see my analysis at http://lwn.net/Articles/288473/).
unless one digs into the actual commits and determines what's going on,
it's easy to make a bad judgement call even for -stable. you know, there
are places that can't just reboot into a new kernel every week for no
reason (Microsoft has patch Tuesday once a month only).
also what about people running older kernels, outside of -stable focus?
do you determine how far back a fix should be applied? i don't think so,
but people maintaining older series will do that, provided they get a hint.
in other words, it's all the more reason to have the commit say it's
fixing a security issue.
what is wrong in particular? when you know that you're about to commit a
patch that fixes a security bug, why is it wrong to say so in the commit?
in what way will people reading that commit be misled? they will see it's
fixing a security bug and they can prioritize it for whatever processes they
have for backports, analysis, etc. if they don't see such marks, they will
have to do a whole lot more work (effectively duplicating your own and even
each other's efforts) to figure out the same. why not save them time and
tell them directly what you already know?
cheers,
PaX Team
--
