> The work that it takes to comprehensively prove to yourself that a bug
> (in the kernel) has no security impact whatsoever is colossal, if it's
> even possible at all.
this is about as wrong as it can get. why? because the correct answer is 'it depends'. there're many many fixes where it's very obvious whether the given bug impacts security or not. in my experience the tricky ones are those that can cause some non-trivial memory corruption and the prudent approach there is to simply call out their potential security impact.
or to explain it another way: consider how the kernel evolves. it's through patches adding/fixing/removing stuff. based on your assumption above we can't actually know if any of those fixes a bug (security ones included). the consequence of which is that to make any statement about the security of linux would take a colossal effort. i think most developers would disagree with you on that but feel free to remind them next time they make some bold statement about how secure linux is.
> [...] it doesn't make much sense to call some bugs out as security bugs
> and thus imply that the others aren't.
back during the summer discussions several people in the anti-security camp had kept repeating this even when it was thoroughly debunked. tell me, where does that implication come from? can you prove with anything (statistics or else) that people actually believe that the kernel has only those security bugs that are explicitly called out as such? because i have yet to see such person and, frankly, such a person wouldn't be in anyone's employment for long as he'd be unfit for any job having to do with the kernel (ever heard of undiscovered bugs, security or otherwise?).
put another way, when i call the sky blue, it doesn't imply that nothing else in the world is.