With So Many Eyeballs, Is Open Source Security Better? (esecurityplanet.com)

Sean Michael Kerner, writing for eSecurity Planet: Back in 1999, Eric Raymond coined the term "Linus' Law," which stipulates that given enough eyeballs, all bugs are shallow. Linus' Law, named in honor of Linux creator Linus Torvalds, has for nearly two decades been used by some as a doctrine to explain why open source software should have better security. In recent years, open source projects and code have experienced multiple security issues, but does that mean Linus' Law isn't valid?

According to Dirk Hohndel, VP and Chief Open Source Officer at VMware, Linus' Law still works, but there are larger software development issues that impact both open source as well as closed source code that are of equal or greater importance. "I think that in every development model, security is always a challenge," Hohndel said. Hohndel said developers are typically motivated by innovation and figuring out how to make something work, and security isn't always the priority that it should be. "I think security is not something we should think of as an open source versus closed source concept, but as an industry," Hohndel said.

Comments

More eyes

[Bengie]

More is better when it comes to bugs that are mostly obvious to the typical person, but doesn't benefit complex code that whooshes over the head of 99.9% of people. My co-workers tell me I have an attention to detail. Some code will get 3-5 people looking at it and testing it over a period of a month or two, then the'll ask me to take a look. Many times I will find several bugs in 10-15 minutes by just reading the code, then I'll have questions about the code and ask them to run some tests that will further find some more bugs.

I do not trust normal humans to anything technical right. I would prefer languages that work better with static analysis, more free tools to provide quality static analysis, and more fuzz testing.

Re:More eyes

[Let's All Be Chinese]

It's not that the patterns themselves have failed, just that their use has fizzled due to failure to live up to the claimed benefits of using them. I've never actually even read the book, but I took a gander at the "antipatterns" book (only thing in category available at the library at that time) and it immediately struck me as "middle management trying to program", or something in a similar vein.

Now, there's indubitably a lot of "code grinders" Out There for whom this sort of thing is actually a boon. The best and brightest among us tend to scoff at such people, or more specifically at their stumbling and crutches, with all sorts of plausible-sounding but not actually helpful counters like "good people know what their code does", conveniently forgetting that most programmers aren't very good at all. So perhaps "patterns" are a useful crutch to keeping a lid on the damage from the inevitable Dunning-Kruger effects in business programming. I don't know, maybe.

But it was only until very much later that I found this writeup and my take-away is that this sort of thing, I think including touting lists of "patterns" as fix-alls for programming trouble, are attempts at taking an inherently mapping mode thing into something suitable for packers to use. The better approach is to knock such people into mapping mode, but that's much harder to sustain. And could well count as cruel and unusual.

Re:Visibility is always better than invisibility

[hcs_$reboot]

I tend to agree. However, on the other hand, Open Source has "so many eyeballs" that most people trust it blindly, which can be dangerous.

Re:Visibility is always better than invisibility

[Bruce Perens]

We've mostly won this battle in the industry. You can't really not use Open Source in your IT department any longer. And IT managers who insist on avoiding it, rather than learn about it, don't get ahead.

Security vs Law Enforcement: 2 impossible missions

[holophrastic]

I have trouble with this industry-concept that software security should be put first -- it's an impossible business objective.

Think about how many industries focus on security. Banks, sure. Money transport, of course. Prisons and jails.

My air conditioner broke last week. It needed a new capacitor. It was a 5-minute $0 fix. Walk between the houses, open the compartment, pull out the breaker.

Now imagine your air conditioner, with the software industry's concept of security. Can you? How many check-points for a repairman to get to my air conditioner? How much added hardware? How much added expense in dollars and time? What stops someone from throwing a paint-filled balloon from fifty-feet away?

Security, when lives aren't at risk, is just so rarely worth it.

And when lives are at risk? Maybe you have a lock on your front door. Maybe it's a deadbolt. Maybe it's a really fancy locking mechanism, super-secure. Your front door is likely right next to a glass window. Congrats on the lock. Enjoy the bars on your windows.

And what stops your car, at highway speeds, from hitting another car at highway speeds? Right, a thin strip of white paint. Excellent. Sometimes the paint is yellow, even better.

We've never focused on security. We simply cannot afford to.

Instead, we talk about insurance, and criminal law enforcement.

So that's what I'm suggesting for software. Law enforcement. Deterrents.

Anything else, well, is just uncivilized.

Re:Exactly. Shallow, not non-existent. Personal ex

[Aighearach]

My experience was, I saw a bug report in some open source and tried to fix it, and by the time I had a patch written a better one was already released upstream and I was the last person to upgrade because I was off trying to write a patch.

There are so many freakin' eyeballs available, volunteers are mostly just jerks like me who are getting in the way trying to help! You have to have an inside line to the developers or security researchers to even learn about a bug early enough to have anybody notice even if you understood it as soon as you heard about it.

Even writing new types of network servers; somebody announced they were abandoning a web middleware tool that was popular, and so I started plugging away at an apache module, but within a week somebody else released something similar enough to mine that I just stopped coding and used theirs. Sure, my architecture choices were better, but theirs weren't bad enough to amount to bugs so nobody would ever notice or care.

Programming is easy, the hard part is finding an unserved use case! And fixing known bugs is a pretty obvious use case.

Start by posting your idea

[raymorris]

Your experiences remind me of something I learned about open source development. I now start by posting about what I intend to do. I've received these responses:

John is working on that and expects to release it next week.

No need to do all that, just use setting Xyx and skip the last part.

That seemed like a good idea, but when we looked into it we noticed this trap.

We decided we want Betaflight to focus on LOS. Your idea fits better with the iNav fork, which already does most of that.

Hey that's a good idea. Can you also allow multiples? That would be useful for me. I can help test.