Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Are All Bugs Shallow? Questioning Linus's Law

kdawson posted more than 4 years ago | from the defending-a-shibboleth dept.

Software 596

root777 writes to point out a provocative blog piece by a Microsoft program manager, questioning one of the almost unquestioned tenets of open source development: that given enough eyeballs, all bugs are shallow. Are they? Shawn Hernan looks at DARPA's Sardonix experiment and the Coverity static-analysis bug discovery program in open source projects to conclude that perhaps not enough eyeballs are in evidence. Is he wrong? Why? "Most members of the periphery [those outside the core developer group] do not have the necessary debugging skills ... the vast numbers of 'eyeballs' apparently do not exist. ... [C]ode review is hardly all that makes software more secure. Getting software right is very, very difficult. ... Code review alone is not sufficient. Testing is not sufficient. Tools are not sufficient. Features are not sufficient. None of the things we do in isolation are sufficient. To get software truly correct, especially to get it secure, you have to address all phases of the software development lifecycle, and integrate security into the day-to-day activities."

Sorry! There are no comments related to the filter you selected.

Bugs are an error in the... (0)

QuietLagoon (813062) | more than 4 years ago | (#31152146)

Bugs are an error in the process, not the code. If you find a bug, you need to find the process error that allowed that bug to occur.

Re:Bugs are an error in the... (4, Insightful)

liquidpele (663430) | more than 4 years ago | (#31152210)

True, but that's not what he is questioning. Given two identical projects that are fairly complex (i.e. an OS kernel) he's saying that just being open source doesn't necessarily provide "more eyes". While I think there is a bit of merit to this, it certainly doesn't hurt to have more eyes possible - especially when you don't have to pay for them. I also think a big difference is that you psychologically don't write shitty code when you think others are going to look at it.

Re:Bugs are an error in the... (1, Funny)

Zebra_X (13249) | more than 4 years ago | (#31152216)

But then again, you get what you pay for so... oh wait

Re:Bugs are an error in the... (5, Insightful)

Statecraftsman (718862) | more than 4 years ago | (#31152248)

We should be careful not to let Microsoft deflect the conversation about software away from the ethics of using software you can't change, provide to your neighbor, or improve when you need more features. If the OPs conclusion is that free software may not have this particular leg to stand on in the arena of technical superiority, we must point out that freedom is our primary concern and that we each focus on security to the extent that we must obtain additional security for our software.

Re:Bugs are an error in the... (5, Insightful)

jedidiah (1196) | more than 4 years ago | (#31152310)

There is a problem of deflection on another level. Most of Microsoft's problems when it comes
to security are design issues. Creating and then enforcing standards and policies with respect
to source code and development process is not going to help if the whole thing is broken as
designed. You will end up with a very consistent turd that looks good on paper.

Buffer overruns and such are not the most serious problem.

Re:Bugs are an error in the... (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31152576)

Since you know so much, point out the design problems in the NT kernel. Lets go for a small number - 10.

Re:Bugs are an error in the... (3, Informative)

Architect_sasyr (938685) | more than 4 years ago | (#31152674)

* File Locked rather than writeable by administrator for upgrade purposes.
* Ring 1 or higher code being able to write to Ring 0 locations.
* Administrative users necessary to run most things (MS software or otherwise).
* Proprietary networking.
* Lack of regression testing (LAND should just never have happened).

There's 5, who wants to take up the mantle from there.

Re:Bugs are an error in the... (1, Insightful)

Bruce Dawson (1079221) | more than 4 years ago | (#31152768)

You need to update your criticisms, and give more details. Very little software on Windows requires administrative privileges -- Vista forced those necessary fixes years ago. The remaining needs for administrative privileges are, by and large, for administration and software installation. You know, the sort of thing that allows locking a machine down securely.

As for proprietary networking, my Windows box uses TCP/IP. What does yours use?

And I didn't really understand #1, #2, or #3. You need to give more details to justify your claims, and preferably to show how they are any different from Linux/OpenSource bugs.

Re:Bugs are an error in the... (1, Insightful)

psulonen (972101) | more than 4 years ago | (#31152624)

Let's see:

Mr Microsoft Man: "Eyeballs alone won't make a kernel secure."
Mr FOSS Man: "Writing unfree software is immoral!"

Let me try this on for a couple of other common criticisms of some FOSS projects:

Mr Web Man: "Safari is way faster than Firefox on OS X and uses less resources."
Mr FOSS Man: "Writing unfree software is immoral!"

Mr Netbook Man: "The Gnome desktop is still kinda clunky, even after all these years."
Mr FOSS Man: "Writing unfree software is immoral!"

Mr Graphic Designer Man: "Linux still doesn't do proper color management."
Mr FOSS Man: "Writing unfree software is immoral!"

Mr Gamer Man: "There aren't any decent games for Linux."
Mr FOSS Man: "Writing unfree software is immoral!"

Who's derailing the conversation here, again?

Re:Bugs are an error in the... (0)

Anonymous Coward | more than 4 years ago | (#31152736)

You seem to think that Stallman still represents the free software community. Luckily for us, he doesn't. There are a lot more level-headed people out there to look at as ideals.

Re:Bugs are an error in the... (2, Insightful)

Anonymous Coward | more than 4 years ago | (#31152658)

Freedom is your primary concern. There are certain ethical quandries that people just don't care about. For example, most people know that the low, low prices at large department stores are directly due to shabby treatment of worker in China and India, but they still shop there. Most people know that the meat, eggs and dairy that most fast food places use come from animals who live in tiny cages for all of their short lives, but people are still ordering sausage-and-egg-McMuffins. In this case, most people don't care (or even know) that the software isn't "free", all they care about is that it works the way they want it to. If you want to support free software (as I do) on ethical grounds, that's well and good. But be aware that you're digging yourself in - alienating those who don't care whether or not software is "free" by telling them that quality and security are lower priority (and if there's one thing F/OSS needs, it's more users, because users => market leverage).

So instead of brashly saying "security and quality" are low priority, why not attack the flawed argument? A F/OSS project will always have more eyes running over the code than a closed source project of equal magnitude. And to those who suggest that the closed source coders are just better, remember that open source needs less LoC (because we can use each others' code, licence and political issues notwithstanding), and as every good coder knows, every line of code is a potential bug, no matter how good the coder. F/OSS gains twice from this - firstly, we have half as many lines, and secondly, our LoCs are read twice (once by the original coder, and once by the guy re-using it). So it's not even a question of whether or not the bug is shallow - it's more that the pool is half as deep.

Re:Bugs are an error in the... (4, Interesting)

Cylix (55374) | more than 4 years ago | (#31152250)

Except the point he is trying to make is that his code is better then the competing individual because he follows process doctrine.

Unfortunately, to make his claims stick he took a failed project as an example to support his theories. While being quite pointed in defining what projects failed he did not cite which projects of his has succeeded. This would have been at least a good starting point for a real argument.

Is good process doctrine wrong? No, it won't hurt of course, but it's not quite a kevlar vest against root shells.

Besides more examples from both sides of the camp he really does neglect several facts. Many open source projects are often led or particpated by professionals as well. In fact a recent article suggested a great more open source projects are corporate sponsored.

It's just an awful piece when you consider he is painting his enemy as both unprofessional and only arming that foe with one failed project example.

Personally, I wanted to read something useful that I could learn from and grow with, but this is pretty standard tripe.

Re:Bugs are an error in the... (2, Insightful)

MikeFM (12491) | more than 4 years ago | (#31152492)

Good process might not hurt but my experience is that it is directly related to how fast many projects get mired down and never write any code. People get so involved in process that they never do anything. Process can be good but you have to avoid letting process become more important than coding. A perfect program that is never written isn't very useful.

Re:Bugs are an error in the... (1)

Cylix (55374) | more than 4 years ago | (#31152618)

I've had that argument posed to myself actually. My manager preferred I post often and clean it up later as the project evolved.

I'm more of a design, document, implement kinda guy. More often then not my initial designs and goals are a bit more complex and generally solved more problems then one.

However, they paid the bills so in the end it's up to my employer on my style. I prefer to make art more then utilities ;)

Re:Bugs are an error in the... (5, Insightful)

the_womble (580291) | more than 4 years ago | (#31152744)

In product after product, Microsoft continues to ship fewer vulnerabilities than our competitors.

I wish he had cited some. It does not seem to be anyone's experience, and the only study I have ever seen that said that Windows was more secure than Linux did so by counting each Linux vulnerability several times (once per distro), and comparing just Windows against entire Linux repositories.

He also looks only at whether more eyeballs are good, neglecting the disadvantage of the uniformity of the WIndows monoculture, etc.

He also argues that the Coverity scan was not an example of many eyeballs because it was government funded. So, the government paid for it - but it still happened.

He does cite some stuff including, hilariously, a study carried out in 2002 that concluded that Linux was close to becoming unmaintainable. Eight years later I am pretty sure it is being maintained.

I am also wondering about the advantages of there beinga lot of code that is shared by multiple projects. I remember a BSD code review catching an X Windows bug. In that particular case it was not fixed upstream because the XFree86 people were being awkward, but I wonder how many cases there are of stuff getting fixed.

It is also easier to report open source bugs. I have never reported a bug in a proprietary app, but I have reported lots of Linux bugs (mostly distro level, or fixable at distro level) because I can follow what it happening, and I know what the (usually good) reaction to my individual report is.

Re:Bugs are an error in the... (4, Interesting)

angel'o'sphere (80593) | more than 4 years ago | (#31152294)


  I also think a big difference is that you psychologically don't write shitty code when you think others are going to look at it.

Coders that write shitty code don't know that they write shitty code. From their perspective the code is just fine and even very good. When ever I told someone I don't like his code and challenged him to explain what he did and why, he only answered: "erm, well that is what the code should do as the requirements demand that", they had no idea what my point was and when I pointed i tout they shrugged and did not understand or value my concerns.

angel'o'sphere

Re:Bugs are an error in the... (4, Insightful)

smash (1351) | more than 4 years ago | (#31152432)

Not necessarily. If its a quick and dirty hack to get something done in a short period of time on a "temporary" basis, then its quite possible the programmer intentionally wrote "shitty code" - and KNEW it was shitty code.

Re:Bugs are an error in the... (1)

shadowbearer (554144) | more than 4 years ago | (#31152508)

/temporary/marketing deadline

SB

Re:Bugs are an error in the... (0)

Anonymous Coward | more than 4 years ago | (#31152636)

this

Re:Bugs are an error in the... (1)

unity (1740) | more than 4 years ago | (#31152632)

I've written a lot of code on short notice for deadlines; but even then I can't say I've written "shitty code" in a long time. But I limit my interpretation in such cases to code that is bug prone and/or hard to read. Anything that is stable and easy to read can be optimized/expanded at a later time if necessary.

Re:Bugs are an error in the... (1)

mindstrm (20013) | more than 4 years ago | (#31152444)

Which is a process problem, right? If the process that is set up is to have coders blindly write code to spec, defined input/output and no other architecture requirements - then the fact that the entire product is a mess isn't that coder's fault - it's the fault of a process that didn't include proper architecture standards.... maybe.

Re:Bugs are an error in the... (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31152336)

FYI, "i.e." does not mean "for example". Please do not make the mistake in the future. I stop reading when people make that mistake.

Re:Bugs are an error in the... (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31152378)

It really gets on my nerves (i.e., it annoys the crap out of me) when assholes (e.g., this guy) go on some worthless rant about grammar.

Re:Bugs are an error in the... (0)

Anonymous Coward | more than 4 years ago | (#31152442)

It's probably just insecurity. Don't worry, when you grow up a little you'll learn to speak and act like an adult and these little controversies will cease to be so important to you.

Re:Bugs are an error in the... (1)

smash (1351) | more than 4 years ago | (#31152438)

What do we have to do to get you to stop posting?

Re:Bugs are an error in the... (1)

shadowbearer (554144) | more than 4 years ago | (#31152524)

  Then you probably miss out on a lot of good information because someone makes a basic mistake.

  IME pedants are usually so busy proofreading they miss the gist of the content. ;-)

  Me included!

SB

Re:Bugs are an error in the... (5, Interesting)

rtb61 (674572) | more than 4 years ago | (#31152380)

What the essay fails to capture is the nature of the functioning of the eyeballs in practice, between open source and closed source. In closed source, the eyeballs only look at what they are paid to look at, if the code is just barely good enough to sell, then out it goes and nobody looks at that code again until the complaints start rolling in and then and only the do they fix it, well, sort of fix it, they of course only fix it just barely enough to silence the noisiest of complaints and the only if there are real consequences for failing to do so. Don't think so then try this http://social.technet.microsoft.com/Search/en-GB?query=this%20is%20a%20know%20fault&ac=8 [microsoft.com] and a huge number of them have never been fixed.

Open source follows a completely different series of routes;
1) People looking for faults because they get a kick out of finding them and fixing them.
2) Tweaks to functions that indirectly remove bugs by simply replacing them with better code.
3) Discoveries in user interactions, less of a complaint because there is no force in pushing the fix.
5) Governments and government departments directly pursuing more secure code.
6) Corporations seeking to build a public reputation by demonstrating coding expertise.

So in the case of open source software there are many 'different' kinds of eyes, so those eyes all working from different perspectives do in reality make bugs very shallow. In the closed source proprietary world the bugs are buried in the depths of the code, hiding in the dark, basically because of profits versus workmanship issues, which means no light is shone on them because only one set of eyes looking from a single 'shallow' perspective looks at them.

There is of course one other set of eyes looking at code, the saboteurs both private and government, looking for faults to exploit. Hard with open source because it can rapidly turn around and bite you on the arse if you use it (if you protect against it everybody notices). Closed source (mostly but a lot of less than honourable eyes lend up looking at it), of course can be targeted as long as you, well, use open source code yourself whilst promoting closed source to everybody else (hmm, kind of reminds me of all those mainland China computer companies, odd that, isn't it).

Re:Bugs are an error in the... (5, Insightful)

shadowbearer (554144) | more than 4 years ago | (#31152390)

  I think that in Microsoft's case in particular, all the exploits out there prove the opposite of his case.

  I'm not a MS dev or even anyone important, just a small business owner who fixes infected Windows machines (it's better than 3/4 of the work I do, sadly) so it seems to me that security wise at least he is way off base - the many more eyes that are looking at MS Windows without even having access to the code base are doing a pretty damned good job of finding security bugs in it.

SB

Re:Bugs are an error in the... (4, Interesting)

grcumb (781340) | more than 4 years ago | (#31152434)

True, but that's not what he is questioning. Given two identical projects that are fairly complex (i.e. an OS kernel) he's saying that just being open source doesn't necessarily provide "more eyes". While I think there is a bit of merit to this, it certainly doesn't hurt to have more eyes possible - especially when you don't have to pay for them.

Agreed, of course. However, the converse is important, too:

Given two identical projects that are fairly complex (i.e. an OS kernel), being closed source virtually guarantees that there won't be 'more eyes'.

But the real question is: How many eyes are enough?

The answer is its own problem: Only one more pair. The tricky part is figuring out whose they are. (Yes, I'm in screaming agreement with what the OP is saying.)

It's a quality issue as much as it's a question of quantity. Ben Laurie [links.org] , writing about the Debian OpenSSL Fiasco [imagicity.com] , states:

[I]f the Debian maintainer [who created the bug] had asked the [OpenSSL] developers, then we would have advised against such a change.

So yes, it does matter whose eyes are turned to a particular problem. The difference between FOSS/Open Source and Closed Source is therefore whether the Closed Source company has hired the right people and whether the FOSS project has gained the attention and interest of the right people.

Neither of those situations is guaranteed, but they are not at all equivalent. (Especially when we consider that for many of the best FOSS products, gaining the attention and interest of the right people is done by employing them.) Realistically, FOSS faces better odds of having bugs found and fixed, all else being equal.

Re:Bugs are an error in the... (1)

fahrbot-bot (874524) | more than 4 years ago | (#31152680)

The tricky part is figuring out whose they are.

Mine.

Re:Bugs are an error in the... (0, Troll)

sexconker (1179573) | more than 4 years ago | (#31152706)

While I think there is a bit of merit to this, it certainly doesn't hurt to have more eyes possible - especially when you don't have to pay for them.

It sure as fuck DOES hurt to have too many eyes.

Too many cooks spoil the broth.
Too many coders will fork your project.

And fuck no, not all bugs are "shallow".
Most bugs you get in open source development are, sure, because you've got tons of people contributing, for free, in their spare time.
Those minor mistakes get through initial submission and eventually get caught.

Many bugs are the exact opposite of shallow - extremely difficult to replicate, isolate, understand, and resolve.
These bugs are typically hardware-related. There's a reason we pay the big boys the big bucks to make drivers and firmware - they need to know what's going on with the bare metal. Running software on top of that isn't necessarily less complex, but debugging it sure as fuck it.

Consider for example the sheer breadth of hardware support offered by MS - both third party drivers, first party drivers, and generic first party drivers for when the third parties can't get their shit together. This is where most bugs a user will ever see come from.

When a bug in your Linux distro pops up, it's not a bug, it's because your hardware isn't fully supported yet.
When a bug in Windows pops up, Bill Gates is a fucking tool and should kneel before Linus.

This mentality is ridiculous, and calling bugs "shallow" is an obvious slight at MS and other companies - "WOW MS couldn't fix this simple bug? Their billions of dollars is no match for the power of OSS! Now how are things going on copying the new Windows 7 interface?"

Re:Bugs are an error in the... (1)

sexconker (1179573) | more than 4 years ago | (#31152746)

"Running software on top of that isn't necessarily less complex, but debugging it sure as fuck it."

Should be

"Running software on top of that isn't necessarily less complex, but debugging it [software] sure as fuck is [less complex].

Re:Bugs are an error in the... (1, Insightful)

Puff_Of_Hot_Air (995689) | more than 4 years ago | (#31152224)

Ahhh, the dream that a perfect process will make up for the imperfect person.

Re:Bugs are an error in the... (2, Insightful)

alvinrod (889928) | more than 4 years ago | (#31152278)

I wouldn't say that your statement is true. It's possible for a defect introduced in the requirements or design stages of development to find its way into the code, but occasionally a programmer makes an error in a loop that leads to a problem; perhaps they meant to use greater than or equal to, but only used greater than.

What process error is that other than human error? There's almost no way to ensure that human error will ever occur regardless of what type of process is being used. You can argue that proper testing should catch the bug, but not all software has the luxury of complete testing, and once again its possible that due to human error a test case is left out. I suppose that you could require the software use a formal methods to get around that, but at that point time and cost are going to become a large issue.

You can't stomp out all of the bugs during development, especially if you have some non-trivial system. One of the major benefits of open source is that third parties can and do spot bugs of this nature and can correct them or notify the developers. It's a recognition of the fact that developers aren't perfect and neither is their code.

Re:Bugs are an error in the... (5, Informative)

Demonoid-Penguin (1669014) | more than 4 years ago | (#31152292)

Bugs are an error in the process, not the code. If you find a bug, you need to find the process error that allowed that bug to occur.

Agreed!

I read, with interest, the referenced article. I was expecting FUD - but I didn't find much, until I reached the Conclusion.

eg.

The many eyeballs argument is neat, tidy, compelling, and wrong.

The article starts with

Eric S. Raymond wrote [catb.org] , “Given enough eyeballs, all bugs are shallow.” He calls this Linus’ law.

and then attempts to refute. Fair enough. Except - the link leads to The Cathedral And The Bazaar - where I cannot find the quote... Hmmm

Now this might be relevant if the "many eyes" routine was the only form of audit used in GNU/Linux - but [nsa.gov] is not [coverity.com] the only [google.com] form of review/audit used. I'm sure other, more knowledgable posters will be able to provide more evidence than I could find in a quick search.

I call FUD

all shills are shallow (0)

Anonymous Coward | more than 4 years ago | (#31152154)

is this the natural follow on?

more shallow than Windows (3, Insightful)

ralphdaugherty (225648) | more than 4 years ago | (#31152168)

They become a lot shallower when you can look at the source code.

Re:more shallow than Windows (1, Insightful)

Demonoid-Penguin (1669014) | more than 4 years ago | (#31152324)

So, given that Microsoft gave the source code to the Chinese government, and that there are a lot of Chinese... perhaps Microsoft products are also subject to the "more eyes" rule....

Just saying.... ;-p

Re:more shallow than Windows (2, Insightful)

Mad Merlin (837387) | more than 4 years ago | (#31152400)

So, given that Microsoft gave the source code to the Chinese government, and that there are a lot of Chinese... perhaps Microsoft products are also subject to the "more eyes" rule....

Just saying.... ;-p

Yes, but thanks to proprietary software, none of those bugs will be fixed, only found and exploited.

Mods (0, Offtopic)

TapeCutter (624760) | more than 4 years ago | (#31152622)

flamebait? - only if windows source code has achieved self awareness and is now capable of flaming.

Yeah, right.... (5, Insightful)

socceroos (1374367) | more than 4 years ago | (#31152176)

As we can all see, this has gone famously for Microsoft.

What do they say? ...the proof is in the pudding?

Re:Yeah, right.... (2, Funny)

iserlohn (49556) | more than 4 years ago | (#31152244)

"The proof of the pudding is in the eating", or as in the case of Microsoft, "the proof of the FUDding is in the beating"...

Insufficient? (1)

Trevin (570491) | more than 4 years ago | (#31152180)

... and integrate security into the day-to-day activities.

Sounds like he's selling something.

PEBCEK is the issue... (3, Insightful)

filesiteguy (695431) | more than 4 years ago | (#31152182)

Unless you're writing some insanely complex application like a launcher for thermonuclear missiles, you pretty much will have user error as a major instigator of bugs.

Until you get your code into the hands of users who - for example - will repeatedly hit the ENTER key wile waiting for a response, you don't have a clue what might happen.

Re:PEBCEK is the issue... (2, Insightful)

shadowbearer (554144) | more than 4 years ago | (#31152338)

  I don't know that one could always consider user error as a "bug" in the software.

  Given the potential variety of human experience and the ways in which software can be misused or abused, it's likely there is no way to make any piece of software "user proof", as you point out. ;)

SB

 

Re:PEBCEK is the issue... (1)

process (447778) | more than 4 years ago | (#31152348)

Unless you're writing some insanely complex application like a launcher for thermonuclear missiles, you pretty much will have user error as a major instigator of bugs.

A launching system for a thermonuclear missile isn't necessarily very complex, it's just vital that it isn't prone to failure.
I think it's probably a relatively simple system, and hardly comparable to an OS Kernel - which then would then be much more complex.

Any authors of thermonuclear missile control systems are welcome to falsify/verify this claim, assuming your Slashdot karma is more worth to you than your job/future/life. ;)

Until you get your code into the hands of users who - for example - will repeatedly hit the ENTER key wile waiting for a response, you don't have a clue what might happen.

AFAIK, usually the BIOS buffers the keyboard input to prevent this from being a problem. Also a typical program won't take keyboard input until it specifically wants to. This may be simplified, but I hardly think this is a good example of a potential problem.

I do see your (badly communicated) point though; yes - Usability testing is important.

Re:PEBCEK is the issue... (0)

Anonymous Coward | more than 4 years ago | (#31152516)

the BIOS buffers the keyboard input

1982 called. It want it's operating system back.

Re:PEBCEK is the issue... (3, Insightful)

Interoperable (1651953) | more than 4 years ago | (#31152368)

That's simply not true. Proper, bug-free code should fail gracefully in the event of odd user behavior. It may be that random mashing of the keyboard will give the user some unexpected results but it should never cause the program to go into a state that it was not designed to go into, such as trying to access 0x00000000.

Re:PEBCEK is the issue... (3, Insightful)

timmarhy (659436) | more than 4 years ago | (#31152686)

if you ever get to write code that is used commerically by 100000000's of users, you'll eat those words i promise.

The fact is, you can only do so much. the more idiot proof you think you have made it, eventually a big enough idiot with break it.

two words for you (1)

r00t (33219) | more than 4 years ago | (#31152700)

kernel debugger

Re:PEBCEK is the issue... (1)

grcumb (781340) | more than 4 years ago | (#31152460)

Posting this only to highlight the perfect irony of the title.

Disagree (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31152188)

Ok, you win. Most open source software hasn't been reviewed very much. Some open source software has security holes, and should not be trusted.

But, all proprietary software should not be trusted, at all. Proprietary software, by definition, has not been reviewed by anyone who hasn't entered into an agreement with the seller. The risk of accidental holes may be less, but the risk of intentional back doors is much higher.

Choose freedom, not some $attribute (4, Insightful)

Statecraftsman (718862) | more than 4 years ago | (#31152206)

This is precisely the kind of argument you become susceptible to if you think that an attribute of software (security) is more important than your freedom. Shawn makes some good points about the technical quality of software and it's true there may not be enough eyeballs to find bugs in free software let alone hands to fix them. What Shawn would have us take from this article is that free software may not be technically superior. It's an attempt to frame the argument and shape what's people think is important in software. Unfortunately, if you care about software freedom, Microsoft's FXCop and PreFast-clean mean nothing. Their software disrespects you as a user and keeps pushing the limits in dividing and taking power away from their user base. Don't buy this line. Choose freedom first and interested parties will take care of attributes like security, ease-of-use, and compatibility over time.

Re:Choose freedom, not some $attribute (5, Insightful)

amiga3D (567632) | more than 4 years ago | (#31152320)

I'm not convinced that Free Software isn't superior. If he'd let us look at his code maybe we could tell. No?, well...without proof it's just opinion.

You're shifting the point (0)

Anonymous Coward | more than 4 years ago | (#31152392)

You're shifting the focus here: the freedom do modify the software is a completely orthogonal topic to improving the software development process. There is nothing that would prevent OpenSource from implementing a better development cycle. Then may be the bugs such as OpenSSL PRNG would not have happened. Dismising his (valid) points, replacing them with a different issue and leaving untouched the premise "may eyeballs produce better quality software (no matter what)" is not productive.

It needs shifting (1)

Statecraftsman (718862) | more than 4 years ago | (#31152596)

I'm not sure if you read my comment closely. I do see his point as valid and we do need more eyeballs and hands on free software(not open source). I just don't want people to miss the forest for the trees. The trees are so many technical, popularity, and quality arguments that are posed by proprietary software developers to obscure a more pressing issue: user freedom. Note, I'm not talking just software freedom here. We need software to live our lives but we also use many services that seek to lock us in, categorize us, track us and direct us to perpetuate ourselves as good little consumers.

You posted as AC possibly because you feel your point of view is not popular on Slashdot but I really wonder. Aren't you concerned about your future freedom when so few companies control not just your communications, your periodicals, but the very instruments(your computer and devices) you use to take in this digital world?

Re:You're shifting the point (1)

martin-boundary (547041) | more than 4 years ago | (#31152602)

What better development cycle? Before I'll try someone's dev cycle, I want to see that it actually works. From TFA's conclusion:

In product after product, Microsoft continues to ship fewer vulnerabilities than our competitors. Look at the results from Jeff Jones blog: http://blogs.technet.com/security/ [technet.com] . Jeff is a Microsoft guy, of course, and thus not an entirely impartial source. But conduct your own research, use your own methodology and I think youll see: in product after product, the Microsoft offering is usually more secure than the competitors. We achieved those results through long-term sustained application of the SDL.

Bwahaha. Nothing to see here.

Re:Choose freedom, not some $attribute (2, Insightful)

shadowbearer (554144) | more than 4 years ago | (#31152556)

Exactly.

  Microsoft is a business that exists to make money. (Obscene amounts of it, if you want my opinion.)

  People who code free software generally do so to make better software.

  I know which one I trust.

SB

Re:Choose freedom, not some $attribute (0)

Anonymous Coward | more than 4 years ago | (#31152740)

People who code free software generally do so to make better software.

I write LGPL software for money. If the bossman stops paying, I stop writing. But damn does freedom feel good.

To get software truly correct... (4, Insightful)

jamienk (62492) | more than 4 years ago | (#31152260)

Since when does MS have the right to say "To get software truly correct..."? They KNOW how to make software secure?

Most Difficult Bug for Me (2, Insightful)

c0d3r (156687) | more than 4 years ago | (#31152268)

One of my most difficult bugs was fixed by simply rescheduling the time a datamining job was to run (which was integrated in to a massive ERP system with other major components of which i had no insight). It took at least 24 hours to test everytime i created a new build. Essentially it was a scheduling ordering issue, where pre-processing of other processes wasn't done in time.. It took me a month to figure this one out. Some times the bugs are outside of the scope of your own system, and the bug will probably re-arise as data grows. I've also had some difficult threading issues where a wait is never notified caused by bad error handling, which was fixed by simply renaming a file (after 1 month of multi threaded debugging with the final session taking 3 days for one execution).

Re:Most Difficult Bug for Me (1)

trajik2600 (944364) | more than 4 years ago | (#31152436)

I understand your pain.... *tears... hugs*

Code fixes (5, Insightful)

JWSmythe (446288) | more than 4 years ago | (#31152272)

    That's kinda funny.

    I spent part of today working around problems with a closed source application.

    The other part of the day has been working with an open source program, where I've already solved the problem, and am documenting my changes to pass back to the author for the next release.

    I'm not a "core" developer for any public projects. I've never submitted a bug fix to someone like Microsoft (but have sent bug complaints that went unanswered). I have sent quite a few bug fixes for open source applications, most of which were used in future release. I'm just another guy, or as indicated, another pair of eyes.

Re:Code fixes (1)

crispytwo (1144275) | more than 4 years ago | (#31152458)

And contrary to MS.BS, competent eyes. Likewise, I have done similar. The premise is that not enough (competent) eyes are looking at the code. This is a faulty premise. In many cases, one extra pair of eyes is more than Closed Software gets.

IMHO, all software will become FOSS over time. There is room for closed source to exist for novel ideas... for a while, until there is a FOSS solution.

Re:Code fixes (3, Insightful)

Kjella (173770) | more than 4 years ago | (#31152606)

I'm not a "core" developer for any public projects. I've never submitted a bug fix to someone like Microsoft (but have sent bug complaints that went unanswered). I have sent quite a few bug fixes for open source applications, most of which were used in future release. I'm just another guy, or as indicated, another pair of eyes.

Well, in my experience what's annoying about closed source software is that you can't solve your own problems. I've reported quite a few defects and gotten quite a few of them fixed, but when you're working with a large vendor just getting through the support organization, down to development and back out through the normal release process means the implementation project is normally over before you get it. There's also a hotfix process but that creates its own headaches both in getting it, running other support cases on the same module and getting rid of it when it's rolled into a normal release.

Sometimes I really wish you could just patch it and roll your own build to solve your own problems. Right now, reporting bugs is more of a chore in the project and really more of a long term investment in not getting as many headaches in the future. I honestly admit there's been times where I've thought "man, am I glad I reported that six months ago" but other times I've cursed that I "wasted" time on support rather than just accept that it'll never work and get what works working and just do damage control on the rest. Ah well, nothing like a little undeserved flak for the consultant.

Re:Code fixes (1)

shadowbearer (554144) | more than 4 years ago | (#31152638)

  I did the same the other day for a proprietary security camera setup software (under windows) which is a fairly blatant ripoff of zoneminder.

  The company that produced this software (some of you may know who I'm talking about) was no help to the business owner I was working for, he'd already spent a few hundred dollars working with their "support techs" - who were unable to solve his problem (conflict with a anti-malware app) and there is almost no support available online even for basic issues.

    I've worked with ZM enough that once I dived into the UI of the proprietary app I had a basic understanding of how it worked, and could solve the problem.

  I'm not sure who I'd submit a bug application to... but I did image his system as part of the $75 four hour fix, and now he knows who to contact to get the thing fixed again if it goes south... happy customer and probably won't see him again for some months, good!

  Many eyes. It's not just the people fixing the code at the basic level, it's the people doing the fixes at the customer level. If we are permitted at least a small amount of understanding of how the system works without buying expensive subscriptions to developer level support vs spending hours online working thru multiple tiers of tech support, we can contribute too..

  I run zoneminder at home, if I have problems I can google a ton of solutions or work out my own...

SB

Silent L (1)

c0d3r (156687) | more than 4 years ago | (#31152280)

Many bugs are caused by the silent L in in the word USER.

Re:Silent L (3, Funny)

deniable (76198) | more than 4 years ago | (#31152634)

I get it, ULSER. Good one. They cause me that sort of stress too.

i don't buy it (1)

Nightshade (37114) | more than 4 years ago | (#31152282)

his argument is also wrong. he's assuming that just because developers are *paid* they are more productive than unpaid developers. how do you know that paid developers are not surfing the web all day? i just don't buy this at all...

Re:i don't buy it (0)

Anonymous Coward | more than 4 years ago | (#31152314)

Heck I'm a paid developer and I am surfing the web replying to this comment :)

always obvious after the fact (1)

Gothmolly (148874) | more than 4 years ago | (#31152296)

It's also why something is in the last place you look - because you stop looking !

All bugs are shallow because eventually someone smarter than you looks at it, and it's obvious to them. How often and how soon this happens in practice is an exercise for the reader :)

With enough eyeballs, all shallow bugs are shallow (0)

Anonymous Coward | more than 4 years ago | (#31152308)

To find the non-shallow bugs you need someone with the right experience and the right way to look at the problem and you simply don't get that by simply throwing lots of eyeballs at random bugs.

Open Source allows the right eyes to see (2, Insightful)

pentalive (449155) | more than 4 years ago | (#31152564)

But at least with open source you can find and apply the proper eyes to software you did not write yourself instead of just trusting the vendor.

Ya it's a joke... (1)

Nikker (749551) | more than 4 years ago | (#31152318)

If one qualified programmer can write a bug and it takes at least one qualified programmer to find that bug then how can it actually be damaging to have many look for the bug, once it is identified even by a "non qualified" programmer others can address the issue much quicker. He seems to try to relate literal depth in the code to the comment "bugs are shallow", while some bugs maybe subtle and complex like all software after QA, first release and further have been completed others maybe be found much later on in the development cycle but they have to be looked for. Most professional (paid to work on the software in question) programmers write the software, debug, submit to QA and hands are pretty much off until they hear back. Something may come to mind later on that he/she may go back and change but who's to say someone professional or not is sitting back and actually discovers a flaw on his own time? Is that necessarily a bad thing? The change still has to be submitted to and committed by the (qualified) team that wrote it in the first place to change their software release. So in short you can't really question "Linus's Law" in this regard because it's only adding to the project, either by feature requests or bug reports. This keeps the software relevant and popular which is a good thing ... right?

Re:Ya it's a joke... (1)

deniable (76198) | more than 4 years ago | (#31152646)

Some bugs are designed by a committee.

Yes. Yes, they are. (1)

shadowbearer (554144) | more than 4 years ago | (#31152322)

  Any technological endeavor human beings work towards will always be subject to "more eyeballs means improvement". If there's not enough eyeballs, then there simply isn't enough people working on the problem.

  I haven't RTFA. but from the summary, most of what this program manager says is intuitively obvious.

SB

Re:Yes. Yes, they are. (2, Funny)

harlows_monkeys (106428) | more than 4 years ago | (#31152708)

Any technological endeavor human beings work towards will always be subject to "more eyeballs means improvement".

So that's why the more people there are on the committee that designed a language or protocol, the better the result. I'd always wondered about that.

Sufficient (0)

Anonymous Coward | more than 4 years ago | (#31152326)

All of those steps? Those are pairs of eyeballs. Electronic ones. This author isn't very critical of his own writing.

He's partly right. (3, Insightful)

slimjim8094 (941042) | more than 4 years ago | (#31152358)

...though perhaps not in the way he intends.

Look, software is *hard*. Building an OS kernel is like assembling a thousand watch movements by hand. You're going to screw up. It's not a matter of "if". There Are Always Mistakes.

Now, when he says "truly correct", I'm assuming he doesn't mean formal proving. That would be absurd, especially for an operating system as complex as Windows or Linux (or really anything with limited resources). Anything short of the formal proof and you just have empirical evidence that it works - but if there's a billion branches and trillions of code paths, nobody will hit all of them with all data.

Fact is, stuff is going to break. You can't prevent it.

So if we can't keep code from breaking - if all significant code is buggy - what's the answer? Well, with open-source code you can find a bug in your application and debug through the kernel itself, finding out why your syscall isn't returning the right information, and fix it yourself. Then everybody benefits from your work - keep in mind, you only did it (or needed to) because your application exposed a flaw. If you're using Linux 1.8 for some unholy reason, well you can fix it anyway (just nobody else will care).

But if you're using Windows, and you get bad return data from a method, your best shot is probably going to be to just coerce the data how you want it. This happens *all the time* in closed-source software - handle a buggy OS method with a special case.

So "many eyeballs" is correct, but not because there are thousands of expert code analysts poring over every git commit. It's correct because any piddly little application developer can debug the kernel itself, following his own method calls around to make sure they do the right thing. Even if he doesn't know how to fix it, he'll be able to say "doThis(*myData) isn't returning the right value" and lead the experts (writers/kernel hackers) straight to a fix.

This is the strength of open source, at least from a code quality standpoint.

Re:He's partly right. (1)

DMUTPeregrine (612791) | more than 4 years ago | (#31152570)

Even with a formal proof you can't be sure there are no bugs. You can prove the code matches a specification, but you can't prove the specification to be correct.

Re:He's partly right. (1)

Kjella (173770) | more than 4 years ago | (#31152742)

Even with a formal proof you can't be sure there are no bugs. You can prove the code matches a specification, but you can't prove the specification to be correct.

I've got one worse, after discovering that the third party software obviously malfunctions and you get past support but you run into a brick wall of coders that claim the project is working according to specification. Try proving that the specification is incorrect and that not even a drunken baboon would purposely make it work that way, but they act like it's the Holy Scripture and infallible because they only talk bits and bytes. Fortunately after pestering them for long enough they usually find someone with a business clue to alter the specification, but you feel like you just managed to convince the Church that Earth isn't the center of the universe every time...

never mentions design or economics (5, Insightful)

bcrowell (177657) | more than 4 years ago | (#31152362)

The funny thing about this article is that he essentially never mentions (a) design flaws or (b) perverse economic incentives to sell defective software. IMO these are probably the two biggest reason why MS has such a terrible reputation on security.

As an example of a design flaw, there are lots and lots of things that MS designed for ease of use, while ignoring security. MS software is way too willing to execute code in an email or on a web page just because they wanted to do something flashy without putting any responsibility on the user to know what the heck was going on. This is a design flaw. No amount of debugging will ever fully succeed in working around it.

The economic incentives to ship buggy, insecure software are also huge. Companies gather revenue by putting out a new version of the software with a long list of features. Users who buy the new version of the software generally have no way of knowing that it's full of bugs. MS is of course infamous for this.

Of course the implication of the whole article is that MS pays people to fix bugs, while nothing like that is going on in the open source world. This is complete nonsense. Most well known open-source projects are written by paid coders. But let's not let facts get in the way of MS advertising.

No design or economics, but there is new Math (1)

shis-ka-bob (595298) | more than 4 years ago | (#31152652)

From TFA

Mathematically, the many-eyeballs argument, and the million-monkeys argument are equivalent.

Yes, but this is only true if N(eyeballs) = 2 million - N(one-eyed monkeys) - 2*N(zero-eyed monkeys). Of course, once we have humans and their eyeballs involved, we will need modify this recently discovered Microsoft monkey-eye theorem. We should inquire if Microsoft considers human and monkey eyes equivalent in order to determine the effective conversion factor between human and monkey eyes.

A Microsoft Creationist would set the conversion rate at infinite, since our eyes are in the image of God, and monkey eyes are not in God's image. I find this ironic, since God is invisible and therefore has no image.

A Microsoft geneticist might argue that the similarity in eyeballs is comparable to the similarity in the genetic code that encodes the eye. This might state the monkey eyes and human eyes have 90% of their genes in common. However, these genetic differences represent a vector in an N-dimensional space, where N is the number of genes required to express an eye. If we assume that human eyes are the reference, we can determine the 'gain' (presumably less than 1) of the monkey eyes of by finding 'eye-gain' vectors of the Monkey eyes. We can then use a standard inner product to determine the 'eye-gain' values for the various monkeys used in this "Microsoft Writes an OS with Monkeys at the Keyboards Experiment".

In either case, Microsoft will need a new Math to support this claim. When the blogging Microsofty proves this assertion mathematically, I will be only to happy to equate Microsoft with monkeys coding an operating system.

I don't think he understands the argument (5, Insightful)

snowwrestler (896305) | more than 4 years ago | (#31152366)

From the article:

One cannot deny the logic. In fact, it is a tautology. If you assume that all individuals have a non-zero probability of finding and fixing a bug, then all you need is "enough" individuals.

Emphasis added by me to show where I think his argument goes off the rails. "Linus' law" does not assumed that each eyeball is a bug fixer--it simply states that bugs are made shallow. Often the hardest part of fixing a bug is knowing about it, and finding it. The open source process makes it easier to do both, even if there are only a small group of coders actually fixing things.

This is not about how many software engineers you have reviewing your code. It's about how your end users can interact with the software engineers.

Don't use a burning broom on a strawman (3, Insightful)

Antique Geekmeister (740220) | more than 4 years ago | (#31152396)

Ladies and gentleman, the article author is making a strawman argument. By transforming the "Linus' Law" into a badly written syllogism, and pointing out examples where _his invented syllogism_ fails, he's implying that closed source is _better_. Unfortunately, the vulnerabilities of closed source are often worse, by comparison and from experience.

Classic absolutist fallacy (2, Insightful)

JoshuaZ (1134087) | more than 4 years ago | (#31152398)

This is a classic absolutist fallacy. The author has taken what is essentially a rhetorical way of stating a more precise claim (that bugs become more shallow with more eyes and that as you increase this number the shallowness increases). The author has then found that that statement in its most general form might not be correct or might not be the whole story. And therefore decides to throw out moderate versions of the claim. I am not impressed.

More Microsoft FUD (1)

blaizer (1199561) | more than 4 years ago | (#31152420)

Newsflash "Microsoft Employee quotes another Microsoft Employee who says Open Source is crap".

I might give the blog some small amount of thought if Microsoft had ever produced any software of any quality whatsoever. Microsoft's area of expertize has always been in marketing and this is an example of it.

More specifically, if you're going to attack the logic of a statement please don't use an argument to authority to do so.

When you bring more heat than light (1)

Progman3K (515744) | more than 4 years ago | (#31152496)

Getting software right is very, very difficult. ... Code review alone is not sufficient. Testing is not sufficient. Tools are not sufficient. Features are not sufficient.

One of these things is not like the other...

Features are to software correctness as apples are to oranges.

Really, do not subscribe me to your newsletter, mr 'program manager'

Re:When you bring more heat than light (1)

mysidia (191772) | more than 4 years ago | (#31152714)

I'm guessing it's a reference to security features.

Such as "UAC", "File permissions", "Protected mode", "Data execution protection", "Firewall".

Or this new technology MS just came up with and will surely soon be patented.. it's called a "Password", and it's really quite innovative -- it's basically a secret code, and the computer won't let you begin to use it or start a program before typing the secret password.

Well, taken separately, they may be not sufficient. He's not considering the combination though of: Auditing, code review, extensive testing playing with and looking at by many people, features, and attack.

Including people searching for vulnerabilities or ways to exploit things, not merely reviewing code. This type of auditing is outside the vocabulary of a company that deals in closed source software -- but with OSS, it can be expected to be a common thing.

Why do we take M$ punditry seriously? (5, Funny)

haruchai (17472) | more than 4 years ago | (#31152514)

Let me rephrase this for him -

"For 25 years, we deliberately chose to ignore the bitter lessons that were learned by the big vendors, to take shortcuts
to ship shit software first and fix it later and to build up massive layers of cruft in the name of backward compatibility. Now we are caught in a nice pickle
as we've spent years trying fill the leaks in our crap - some of which is so insecure that, 8 years after the launch, we still have record numbers of bugs in
Windows XP almost every fucking Patch Tuesday -and restructure it into something rock solid.
However, until we can get this done, we need to play smoke and mirrors, convince you to toss Win XP - and your old PC, most likely, buy our latest
and greatest and spit out evermore FUD about how nobody else can get stuff done except us.

Ladies and gentlemen, I give you the M$ business plan and I'm pleased to say that it's working as well as ever and thank you all"

Did anyone ever believe it in the first place? (1, Insightful)

BlueBoxSW.com (745855) | more than 4 years ago | (#31152540)

I'm all for open source software. I could give you a dozen reasons why it's a great thing.

But does anyone REALLY believe it's bug-free because there are lots of eyeballs on it?

From the first time I heard that argument I thought it was laughable and not backed by any solid evidence.

He's attacking that argument for a simple reason: Because he can. It's a stupid argument.

And he's getting people all worked up and distracted over it.

Meanwhile, in the next room, Microsoft salespeople are convincing your boss they need to switch all your licensing to a yearly subscription model, and that there's no reason why you should actually OWN the software that you're paying all this money for.

Re:Did anyone ever believe it in the first place? (1)

mysidia (191772) | more than 4 years ago | (#31152730)

But does anyone REALLY believe it's bug-free because there are lots of eyeballs on it?

You are drawing unwarranted absolutes.

There will be bugs because features are being added at a rapid pace, and not everyone fully uses/tests every feature.

It's not expected to be bug-free or even for bugs to be found until years after release of a certain kernel.

Presumably updates to the stable kernel series should remove such bugs as they get found and reported.

Re:Did anyone ever believe it in the first place? (1)

mysidia (191772) | more than 4 years ago | (#31152752)

P.S. It's not expected to be bug free but to have a much smaller volume of noticeable bugs than closed-source software release of equivalent age and complexity, after elapse of a bit of time.

Of course more complex closed-source software can be expected to be more buggy, and younger closed-source software can be expected to be more buggy.

The surprising result that is predicted by Linus would be that when unstable/development OSS released first at time X, while at the same time similar unstable/development closed-source is released at time X...

After a duration 'Y' elapses, the OSS software is much more stable after various releases than the closed source software (over the same time period)

Due to the 'many eyes' finding the issues in the OSS software code. And the closed source nature of the other product resulting in lots of bug reports (potentially), but many unfixed, and in any case, much fewer of the actual bugs addressed than in the OSS software for the same time period and usage patterns.

Let me be the first to say (1)

codepunk (167897) | more than 4 years ago | (#31152598)

bla, bla, bla ,bla, bla

NEWS! (5, Insightful)

nudicle (652327) | more than 4 years ago | (#31152620)

Ok, I've got some news for you. The quotation is not meant like an immutable law. There's a really good, important point there, but it's still just a meaningful aphorism. Let me help you with this -- when you see "given enough eyeballs, all bugs are shallow", read it as "given enough eyeballs, [almost all] bugs are shallow". Does that help? Can we move on now? This discussion is so stupid it's almost painful. Here are some other things to know: MS blog author wants attention; ESR is a self-important moron. Thank me later.

Irrelevant..they are. (1)

mooneypilot (1157115) | more than 4 years ago | (#31152630)

Like they know anything about finding or fixing Bugs...Puuleeze. I take anything I hear from Redmond as complete BS, Except for news of Ballmers termination/resignation..at that point, I go ALL-IN on their stock.

Bugs Exist Because We Use the Wrong Software Model (1, Funny)

rebelscience (1717928) | more than 4 years ago | (#31152666)

Of course, humans cannot think of everything, but with the right software model and the right tools, we will be able to. For the same reason that we use tools to perform complex calculations flawlessly, calculations that we use to have an extremely hard time doing reliably manually. We don't have the right software model in which to construct rock-solid applications because we are not thinking outside the box. We are addicted to our way of doing things.

I defend the hypothesis [blogspot.com] that the two major crises that afflict the computer industry (unreliability and low productivity) are due to our having adopted the Turing Machine as the de facto computing model in the last century. The thread concept (algorithm) is fundamentally flawed and the use of multithreading in multicore processors exacerbates the productivity and reliability problems by at least an order of magnitude. The only way to solve the crisis is to switch to a non-threaded, non-algorithmic, syncrhonous (deterministic), reactive and implicitly parallel model.

The big surprise in all this is that the solution to the crisis is not rocket science. It is based on a simple parallelizing concept that has been in use for decades. We already use it to simulate parallelism in video games, simulations and cellular automata. Use two buffers; while processing buffer A, fill buffer B with all the objects to be processed during next cycle. When buffer A is done, swap buffers and repeat the cycle. Two buffers are used to prevent racing conditions and ensure robust timing. No threads, no fuss and the resulting code is deterministic. We just need to take the concept down to the instruction level within the processor itself and adopt a synchronous reactive software model. It's not rocket science.

Folks, the days of Turing, Babbage and Lady Ada are soon coming to an end. It's time to wake up and abandon the flawed ideas of the baby-boomer generation and forge a new future. The boomers were wildly successful but this is a new age, the age of massive parallelism and super complex programs. The boomers need to retire and pass the baton to a new generation of computists. Sorry but that's the way I see it.

It's a fair point, with regard to security (2, Interesting)

Edgewize (262271) | more than 4 years ago | (#31152672)

Open source bugs get fixed because people notice and are bothered by the bugs. This is the biggest motivator of open source contributions - everybody has an itch to scratch. The bugs that get fixed fastest are the bugs that are encountered the most. And this is why the Microsoft guy is absolutely correct in his analysis.

Bad security is not a user-facing bug. Unlike functionality bugs, there is little incentive for community members to identify and fix security bugs. Sure, the Linux kernel and other key packages will attract expert eyes, but the average random piece of open-source software will not.

Security analysis is both complicated and un-glamorous. There are not a lot of people attracted to that kind of work. There are even fewer people who would do it for free. The position of the linked article is that it's better to pay people to think about security than it is to rely on the principles of OSS. I agree 100%.

Hogwash (1)

mysidia (191772) | more than 4 years ago | (#31152676)

... Code review alone is not sufficient. Testing is not sufficient. Tools are not sufficient. Features are not sufficient. None of the things we do in isolation are sufficient. To get software truly correct, especially to get it secure, you have to address all phases of the software development lifecycle, and integrate security into the day-to-day activities."

What is it you are trying to sell exactly? Microsoft Secure Development Lifecycle?

"Eyes" on the source code aren't just code reviewers... they also consist of the attackers. Ok.. attackers have to find vulnerabilities to exploit somehow. The same techniques used by would-be attackers against the source to find exploitable holes can be used by the community (with source code access as a pre-requisite) to more effectively and with greater number people searching for things they can take advantage of, the more likely any issue is quicky found.

The only way to find faster, would be perhaps for someone to offer a bounty for anyone finding verifiably exploitable privilege escalation or remote exploitable security bugs in a default build of a stock kernel :)

The funny thing is... even addressing "at all phases" of the software development lifecycle and "integrating security into the day-to-day activities" is not enough to be secure.

Observation: This is the closest thing I believe I have seen so far, to an admission, from a Microsoftian, that their software can be inherently insecure (by design).

Seeing as the initial design is one of the most important parts of the software "lifecycle" by some views of the situation.

But the above quotation didn't argue merely AGAINST more eyes. It argued that essentially you can't make software more secure by looking at it, having code reviewed, and testing it.

That's absurd.

While there can be security weaknesses that won't be detected by thorough testing or code review, very large classes of security weaknesses can be.

Also, the complexity of the software systems interacting comes into play here...

Applications with simple well-controlled interactions and stable API (E.g. not like Windows) are less likely to have security issues that can escape a good code review.

FUD (3, Insightful)

mbone (558574) | more than 4 years ago | (#31152716)

One big piece of FUD here is the notion that Microsoft programmers are paid, while open source programmers are not. The open source projects I know of advance mostly because of paid programmers, and I suspect that that is the case in general. That gives them the usual capitalist incentives for finding and removing bugs.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?