Many eyes theory conclusively disproven | Hacker News Reader

Many eyes theory conclusively disproven

blog.erratasec.com

29 pointsjvoorhis20 comments

I think there's a problem with this reasoning, which is that it may be that these bugs are discovered now only because they are open source, and many more such deep bugs exist in closed-source software.

The flip side of the boon that is code reusability is software monoculture, which means that a significant bug in a core library can have catastrophic effects in many systems, so it's likely that the most severe bugs are rarest (hardest to observe), but the longer they go undiscovered, the more catastrophic they will be. It may be that while we'll find some deep, 20-year-old flaws in core open source code, we'll find way more 20-year-old flaws in closed source code, except we'll find them in 5 years, after the Internet of Things has taken off and a serious bug will be 100x more dangerous.

This bug was found by a Redhat security auditor. It's a bit unfair to pose this as an obvious bug that should've been found at any point in the past 25 years, because I'm pretty sure that Redhat has had security auditors for a long while. Although probably fewer in number than Microsofts security auditor team they are likely faced with the same problem:

A huge backlog of old crufty software written in arcane style using programming languages that discourage proper structuring, riddled with bugs promoted to features for backwards compatibility reasons.

What we really should be doing is reimplementing software like this, learning from predecessors, and making sure software that depended on bugs of the past are fixed so they don't. Since we're in the open source world, we don't have to end up the same as Windows did.

> Many eyes theory conclusively disproven

Really? Using as evidence an example where a security auditor reading open-source code found a serious bug?

The fact that few serious bugs are found by reading open-source code may reflect their infrequency rather than the notion that "many eyes" isn't realistic. Heartbleed was also discovered by auditors reading open-source code files.

Claiming that Shellshock's discovery "conclusively" disproves many eyes is like saying that a cancer diagnosis proves that one shouldn't visit hospitals.

I don't know the details behind these discoveries, but weren't they found by security researchers looking through open source code?

Wouldn't that actually support the theory that open source is "more secure"?

Are there any studies done on bugs found in proprietary packages that could give a better definition to "fewer security problems"?

"Companies like Microsoft pay programmers to review code..."

Apparently these (well-paid) MS programmers don't do their job well

http://www.dailytech.com/Appalling+Negligence+DecadeOld+Wind...

My eyes went to this immediately:

"..outdated softwae at America's largest home improvement retailer"

Article lambasting Microsoft for not reviewing their product enough before it gets sent out, sends out a product that clearly wasn't reviewed enough.

> "The average programmers writes 10x more code than they read."

Not in my experience. And I certainly wouldn't trust such programmers.

This is completely surprising to me as well. I can't even imagine what a person like that would be like, at the workplace. I certainly have never talked to one. If you ever meet a programmer that talks 10x more than he listens, please show me it.

Some nice, peer reviewed research about this topic entitled "An Emprical Study of Linus Law": http://www4.ncsu.edu/~apmeneel/ccs221-meneely.pdf

I wonder how many bugs go unreported because the team or individual responsible for the code-base is too difficult to deal with it's not worth the time.

Those that aren't indifferent to feedback are often hostile to it and will get pretty aggressive when you point out flaws.

Additionally, many of these code-bases are so esoteric and needlessly complicated, many with quirky coding styles unique to the project or with layers of meta-programming that makes it hard to understand what's actually going on unless you've actually worked with that project for a while.

When I see M4 in a project I just sigh and move on.

Most programmers don't spend their time bug-hunting in crappy codebases.

Most programmers wouldn't recognize a security bug, unless there were making a point of thinking that way (and many wouldn't even then). Which takes extra mental effort.

Base-system and network-facing software should be written in a way that makes it fun to read and useful to learn from, so that it gets more people looking at it.

Base-system and network-facing software should have open, friendly maintainers, who welcome questions from new learners trying to understand the code.

Some bugs would never be apparent from just reading code. Telnet over an untrusted network is insecure no matter how well written the code is. Priority inversion is only apparent looking at a system as a whole. An overly-concurrent system may work find on a single CPU, but start thrashing itself when run on a big NUMA machine.

These would seem to require a higher understanding of the system, and more specialized skills to detect. I'm not really sure what aside from having good design documentation to do to make them easier to find.

The article claims few eyes are looking at open source code, which is not necessarily false, however that claim must be contrasted with even fewer eyes are looking at proprietary source code. Security through obscurity is not a well-regarded practice and in fact the United States National Institute of Standards and Technology (NIST) recommends against it.

If many eyes had been looking at bash over the past 25 years, these bugs would've been found a long time ago.

Many eyes switched to different shells, or never used bash to begin with. We have sh, dash, zsh, fish, depending on need and circumstances.

What an absolute joke of an article.

Keep in mind that, unlike Windows and OSX, GNU/ Linux doesn't have a paid media arm to make bloggers turn security issues into a huge spectacle. With how vulnerable to malware and generally insecure Windows is, can you imagine what it would be like if the media applied the same level of scrutiny to it? You wouldn't be able to find a story on some online journal that wasn't about a Windows security hole.

In my opinion we have to say goodbye to the idea that something is intrinsically more secure for an other reason than being specifically designed for security. On the other hand I'm not sure who seriously still makes the claims that Graham critizises.

Eric S. Raymond for one.

https://en.wikipedia.org/wiki/Linus%27s_Law

Guess that should be renamed to Linus's Fallacy.

To be fair, Linus's Law was meant to apply to all bugs in general, not particularly to security bugs.

Though it can be argued that, given that human nature makes people more prone to go looking into things when there is a (perceived) problem, Linus's Law applies only to the subset of bugs that affect functional requirements of software.

The context where ESR coined "Linus's Law" was one of describing how FLO development could be surprisingly effective. "Someone will see an easy way around any given issue" has nothing to do with "there will be no security critical bugs". Neither "secure" nor "security" appear in the section of CatB under discussion there, and they only appear in the wiki article in reference to separate supporting evidence in a security textbook.

I will grant that the longer formulation's phrasing of "almost every problem will be characterized quickly and the fix will be obvious to someone" could be interpreted as including obscure security issues, but 1) this could reasonably be part of (every - almost every), and 2) I think it is best to separate the finding of a bug from its characterization - the typical invisibility of security bugs from a functional standpoint certainly means that security audits and best practices are not appreciably less important for FLO software than proprietary software. Any effect of "many eyes" on security absent visibility should be expected to be marginal.

The biggest benefits from open source, from a security standpoint, are probably that it enables truly independent audit, and secondarily that it promotes coding as if your code will be published and scrutinized.

"The average programmers writes 10x more code than they read."

I am way below average. I read a ton of code for every line I write, though I guess that's since I'm usually doing more work on bug fixes than features.

Reply on news.ycombinator.com