User: Password:
Subscribe / Log in / New account

Kernel security, year to date

Kernel security, year to date

Posted Sep 9, 2008 21:13 UTC (Tue) by branden (guest, #7029)
In reply to: Kernel security, year to date by spender
Parent article: Kernel security, year to date

Is that the the rhetorical "you" you're referring to?

(Log in to post comments)

Kernel security, year to date

Posted Sep 9, 2008 21:36 UTC (Tue) by drag (subscriber, #31333) [Link]

Ya. It's a bit strange. It's like he is blaming me for the security problems or something.

> You've enabled them to not report security issues. You've made your bed and you'll have to lie in it.

You (spender) sound like you have somebody in your head that your arguing with that has nothing to do with the editor/writer of the article or anybody else that would happen to read your reply. Maybe you should spend a little less arguing with your imagination before writing a reply next time you have something you want to say.


Kernel security, year to date

Posted Sep 9, 2008 22:00 UTC (Tue) by spender (subscriber, #23067) [Link]

You, as in, you Linux users (who read this site) who when this issue of kernel security was raised recently, said "you're right Linus, security bugs are no more important than normal bugs, you and the rest of the kernel developers don't need to waste any of your precious time on informing me of any of the exploitable vulnerabilities found in your software." You, as in, you Linux kernel developers (who read this site) who refuse to acknowledge these fundamental problems, and instead of taking steps to correct them, cover them up or ignore them.

As I don't remember you (as in you, drag) speaking up when this issue was last raised, then yes, your implicit acceptance is partially to blame for the new non-disclosure policy of the kernel developers. It would not have been possible for them to adopt this policy in the presence of general public outrage.

But of course, taking this discussion to a meta-level of what I mean by "you" is much more productive.


Kernel security, year to date

Posted Sep 9, 2008 22:13 UTC (Tue) by drag (subscriber, #31333) [Link]

> You, as in, you Linux users (who read this site

Your talking to imaginary people. So stop it.

This is a obvious effort to continue some flame war with people you've forgotten the names of (or your trying not to be so obvious)) and your hoping that they'll pick up the bait and start arguing with you again.

You have important things to say (in fact, your essentially agreeing with the person that wrote the article, BTW), but your clouding your message with this silliness. Trying to pick fights is a waste of everybody's time and is putting you off-message. In other words; your trying to start a flame war. If your post lacked content then I would not have hesitated to label you a 'troll' and wouldn't be talking to you right now.

(I am assuming your trying to impress on everybody the need for higher coding review standards in the kernel, which is a worthy thing)

Kernel security, year to date

Posted Sep 9, 2008 22:58 UTC (Tue) by nix (subscriber, #2304) [Link]

Face it. You're not going to get 'general public outrage' about *any*
computer security problem unless it causes mass death, and even then it
might not happen. Security is a boring overhead to most people, so any
scheme which attempts to change anything in the security domain by
attempting to incur 'general public outrage' is guaranteed to fail.

(What's more, it's tiresome. Fixing the damn bugs is surely more
worthwhile than complaining endlessly about them.)

(Also: compared to a lot of code in critical positions, the security of
the kernel is pretty damn good. A while back I looked for security holes
in the product I work on in my day job, which throws many millions of
dollars around in the financial markets on a daily basis and is often
intentionally (!) left exposed to the Internet at large. I gave up when I
realised that the security hole density was approximately one per twenty
lines, generally enormous buffer overruns, trusting of untrustworthy data
from completely unauthenticated external sources, and SQL injection
attacks up the wazoo. I tried to convince my coworkers not to introduce
more such bugs, but nobody else considered any of these things
problematic. You can always trust external data, can't you? And if bad
stuff comes in, well, it's not *your* fault. Blame the attacker.)

Kernel security, year to date

Posted Sep 9, 2008 23:49 UTC (Tue) by drag (subscriber, #31333) [Link]

If you want to apply your evilness towards a creative goal check out Linux-hater's blog.

If you compile a list of vulnerabilities and memorial quotes from Kernel developers regarding security then that is very very likely to attract attention.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds