The thing is, ordinary bugs can also be security bugs.

People that fix ordinary bugs then also end up fixing many security bugs that are not classified as such. These are the unsung "heroes".

I think his point is that the important part is working on fixing bugs, and not making a show out of finding security ones.

The guy that fixes an unexploited critical remote code execution or privilege escalation bug is no less (and no more) a hero than the guy that unearths a file-system bug silently corrupting data.

So in my opinion he's right: both are equally important, as you cannot judge of the importance of each one on purely speculative and gross domain grounds. A potential is just that: a potential, until it gets real. Both cases can be mitigated or prevented by applying similar strategies (redundancy, layered checks, ...).

On the other side of the spectrum, a good bunch of Intel video cards have been crashing randomly (ranging from seconds to hours) since years and it affects a good deal of people which have to revert to vesafb or fbdev, or dismiss Linux entirely, right now. Another one is the issue introduced at some point that makes kworker eats up a chunk of CPU for no apparent reason (from 10% to 100%), resulting in useless wakeups and processing, raising power use by 1 to 10W. Multiply that by the growing number of Linux systems using 2.6.35+ and you get quite a bunch of watts that should have never been produced by power plants nor paid to energy companies by the machine owners. It happens right now with real, tangible effects.

I'm not dismissing security bugs, but put things into perspective as things are not black or white, and every single bug matters.

Please read this, here is the point of the discussion, I think this more informative text should have been linked:

http://lkml.org/lkml/2008/7/15/498

He simply doesn't want to make it easier for "exploitz searchers" to recognize which bug patches are "easy to make an exploit."

Agreed. His broader point about not "glorifying" security researchers is valid, but he goes way too far when he says security bugs aren't more important.

There is no point in telling him he's wrong, either. He'll just call you a "masturbating monkey".

So what you are saying is that security fixes should be highlighted separately from regular bug fixes? That in a release, these security fixes should be highlighted and made clear specifically what security fixes went into place?

Because that is what is being discussed here.

This is at the end of the day just so silly. Besides the fact that this is an argument from something like 3 years ago, it's also the case that Linus and the kernel development team just don't have to have anything to do with this process. If you want to pursue secret handshake security for Linux code, set up a project to do that. Projects doing exactly that date back to the mid '90s.

Is this really anything more than yet another opportunity for message board geeks to go "RARRR!"?

"This is at the end of the day just so silly."

What is silly? Really, I have no clue as to what you are trying to say.

So what if he's wrong about that? You don't get a prize for winning that argument; he's still Linus, Linux is still going to be the dominant server platform on the Internet, and he doesn't have to take security any more seriously.

The fact is, despite that one obvious nit with his comment, if you take what he's saying in context, he has a very valid point about how the security community interacts with the Linux development community.

Linus absolutely correct describing this refusal of the monkey's to see anything else beside the matter at hands. The security isn't the main goal of the server development. Successful development of the server is the _goal_ and security is just a necessary piece, among others, in the much bigger picture. Linus understands it and thus he's successfully managed to deliver for 20 years where others, more weak minded and weak willed, have succumbed to the process, security and others monkeys.

Tell him.