Review your favorite Linux distribution.
Go Back > Blogs > Musings on technology, philosophy, and life in the corporate world
User Name


Hi. I'm a Unix Administrator, mathematics enthusiast, and amateur philosopher. This is where I rant about that which upsets me, laugh about that which amuses me, and jabber about that which holds my interest most: Unix.
Rate this Entry

It's all about the *right* eyeballs...

Posted 06-17-2011 at 12:17 PM by rocket357
Updated 06-17-2011 at 12:21 PM by rocket357

If you don't test something yourself, can you trust the information you find about the topic? The biggest difference between blindly trusting something and knowing the answer is having the right eyeballs. In other words, if you setup a test case to cast the data in the right light, you can see the answer plainly. You need the right eyeballs.

The reason ESR's statement "with enough eyeballs, all bugs are shallow" is (somewhat) correct is that no two people look at a problem the same. Each has a slightly different approach, and with enough eyeballs in the pool odds are good that one is going to look at the data in just the right manner to make the bug obvious. Grats to ESR for pointing this out, right? We can all go home and trust our FOSS software vendors now, right?

Not exactly. The statement has one critical flaw.

"with enough ***QUALIFIED*** eyeballs, all bugs are shallow" is a bit more correct. If I take microscope pictures of a cell scrape and show them to millions of people, none of whom are doctors, nurses, or such, odds are pretty low that any one individual would be able to tell me anything significant about the pictures.

Does this image indicate genetic disease?

Who knows? I'm still trying to figure out WTF I'm looking at!

Theo Deraadt made a similar comment during the FBI/OpenBSD controversy a while back...a claim was made that the FBI paid former OpenBSD developers to plant a backdoor in the OpenBSD IPSEC stack, and accordingly a massive code-audit was started and many trivial bugs were fixed, even though no backdoor was found. Who were the code-auditors? General population? OpenBSD users? OpenBSD devs?

The VAST majority of the public auditors were OpenBSD devs. I think there may have been one individual who publicly audited the code who was not a member of the OpenBSD team. The entire world was given an opportunity to find a flaw in OpenBSD and claim fame in security circles worldwide as the individual who found a backdoor placed in the most secure general-purpose operating system in the world...a backdoor that had survived TEN YEARS in an open source project without being discovered...a backdoor that was engineered by a government agency (or, more accurately, operatives of a government agency) that might have the resources to actually pull it off...and yet, only ONE person stepped up publicly? Sure, there were probably quite a few who "stepped up" quietly and reviewed the code (I took a look myself, to be honest), but of all the bugs fixed, how many were from non-OpenBSD devs?

When the topic at hand is highly specialized, as code auditing for security problems is, there tend to be very few qualified "eyeballs" available...tossing ESR's hypothesis out the window.

So how do you go about getting "qualified" eyeballs on a subject when you have a question? Should you ask someone else? Sure, you might find a qualified individual if you are asking simple enough questions (sites like thrive because of this)...but then you have to trust that individual's answer.

Nah, it's better to dig in and test. How can I verify that I'm transmitting data in an encrypted fashion to a friend? Wikipedia for the protocol you're using? tcpdump? How about testing if a file is readable by unauthorized users? ls -lh? Login as someone that's not supposed to have access and try to read it?

When I was in college I wrote a rootkit for Windows Server 2003 (for a security course I was taking). I then used that rootkit to demonstrate that the "netstat" command on Windows Server 2003 was untrustworthy (TCPView from sysinternals did see the connection I was hiding =).

Think about who you're trusting when you take information in. Who generated the information? Are they trustworthy?

And then ask yourself the most important questions: How much did I learn by testing it myself? How many times did I have to stop and ask someone for an answer when I was testing it myself?
Posted in Uncategorized
Views 810 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 09:17 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration