> most of the time the developers are interested in fixing bugs for the sake of fixing bugs.
fine by me, also completely irrelevant for covering up security fixes.
> Analysing the fix to tell if there are security implications of the fix [...]
you can stop right there. noone asked them to do such a job. they're not even qualified for such a job. what we did ask them is to be honest. if i find a security bug and provide a PoC exploit for it, i *want* to see the commit of the fix mention the fact that it's fixing a security bug. this is not negotiable. the kernel policy is diametrically opposite to this, Linus explicitly stated that he would even *censor* any such mention of security related info in commit messages. no wonder i stopped submitting such fixes upstream and keep them in PaX instead. as a security professional yourself, i'm sure you appreciate my covering up said fixes though (see, who said i can't accomodate stupid policies ;), i expect a pat on the back at least ;).
> In addition to this, many of the same people consider anything that tags
> only some of the real security fixes as being security fixes to have a
> negative value,
define many. i only recall Ingo and perhaps Linus ever saying something stupid like that and when i asked for the *reasons* behind such an opinion, i got nothing but BS. maybe you've got better ones?