Slashdot Mirror
Open Source Security: Still A Myth
jpkunst writes "John Viega (coauthor of a.o. Building Secure Software) argues in Open Source Securitey: Still A Myth at O'Reilly's onlamp.com that "open source software may currently be less secure than its commercial counterparts.". According to him, there may be "more eyeballs" looking at open source software, but he does not believe those eyeballs are looking for security problems in a structured way."
... once something is actually found, it's fixed a lot faster than in most commercial software.
What about more eyeballs meaning a faster fix?
The difference is that when a security hole IS found (whether it be by the good guys or the bad guys), it gets patched VERY quickly compared to commercial software...
Others will say, "Open source developers are more clued in to security issues due to a better sense of community, and their software is more secure as a result."
He's right. They may not be looking for security holes and they may not find them because of all the "eyeballs" but they will certainly fix them and release a patch to the community shortly after it is discovered.
Now, even if MSFT did release a patch right away it wouldn't make much of a difference as most people don't update their software. The OSS community, OTOH, is still mostly comprised of people that have a Clue and those people generally patch immediately.
So while what the article states is true currently the OSS community does respond faster and with less problems than their counterparts on the other side of the fence.
Corporation's view on security is even less structured.
Actually, corporations are not concerned with security at all ! They are in a business of making money, not secure products.
Now the million dollar question: Who paid this guy ?
In the land of the blind, the one eyed man is king.
They believe it, but offer no proof. You don't create an OS kernel by hacking in bits of code, you don't create any complex software by just "hacking" it together. Mozilla, OpenOffice, KDE, GNOME, all the major pieces of Linux software, in my opinion, are very structured and follow a solid design process.
As opposed to the general "closed source" software method of finding bugs/security holes by accident, sweeping them under the rug, and hoping nobody finds them?
Are you serious?
Here a little example.
Question:
How many non-skilled programmers looking at complex security code does it take to screw in a light bulb.
Answer:
Only 1. The one who can look at it, understand it, and then implement a fix for it.
The whole many eyeballs thing is a myth that is more common then the OS security myth (ok that was a bad joke). Really though, can you find and plug security holes in code? Can your friends. OSS is maintained pretty much the same as closed source software, by a team of dedicated people who enjoy doing it. The only difference is that with closed source software the people enjoy the paychecks, with OSS the people enjoy the process.
More eyes does not mean better security in the least, it just means more people looking at code and saying "What the hell is all this"
Be well.
Busy eyeballs are better than idling eyeballs.
Well, yes and no. Read your closed, proprietary license agreements. ALL software is sold AS IS without warranty as to merchantability or fitness. The companies are not "on the hook" in any sense of legal liability.
They are "on the hook" in the sense that, if the market decides their product is poor and there is a alternative product, the market will move there. In that sense, and in that sense only, closed vendors are "on the hook." Of course, this presumes the existence of a competitor. Does Microsoft have competition? In some markets, yes. In some, no.
So a product without a competitor is no different from an open source product. However, I would argue that market forces act on open source as well. The competition is for developers. Developers will work on a project that is useful and is used. They will tend not to work on projects that are not used. In this space, too, some open source products have competitors and some do not.
Money is not the only market force.
As an IV&V tester (Independant Verification and Validation) I concur with the article. Sure, many eyes helps, but without a proven testing methodology, thought out and complete testing procedures and stylized reporting, bugs/security holes could go unnoticed for a long time.
Jesus no. If that happens, I will be grepping for "rewards" and similar strings without actually doing anything. The people incharge of big/popular/successful project already take care of these things to being with during the 'design' phase. That is also a part of the reason that these projects are big/popular/successful to begin with. Look at Apache and you will get the idea. More eyeballs != More security. But its the whole flexibility that once something is found, even you can write an internal patch if you are an org running open source software in case you don't feel like waiting even a day or two for the community to release it.
Free XBox, PS2
Has this guy been working with better vendors than I have? I had to deal with vendors on a regular basis who let some pretty awful stuff slip through QA and some of them could be very defensive about accepting that a bug existed. I had to threaten to shut down multi-hundred thousand dollar contracts to get action sometimes, twice I actually did call bullshit on a vendor and abort the contract.
Money provides a stick to get vendors to fix their problems, but they still have human beings working on their products, and like all human beings they make mistakes, get defensive, have better things to do with their time, etc. Also success (money) can breed indifference in a vendor, once you have a good portion of the market and have people locked into your offerings you have to be just good enough to keep the cost of the customers irritation with you lower than the cost of switching to another product.
[Set Cain on fire and steal his lute.]
The problem, as the author points out, is that many eyeballs do not equal "eyeballs in depth" or "coordinated eyeballs". The housefly has thousands of "eyes", yet that doesn't make it necessarily more visually acute (contrast it with, say, the eagle or the falcon).
I would suggest that, if you are going to code a secure product, that the people and processes that make up the audit team should themselves be auditted. The flowchart of security shouldn't start at the product itself; it should start at the people and processes that produce the product. Otherwise, what you would end up is a lot of people "reaching for the low-hanging fruit" (as the article suggest), making flashy features work, while the obscurer and necessary work get ignored or done poorly. Security must be managed from top down, not invented along the way by coders.
Apache is a perfect example of this. Patchy describes it very well. While the recent 2.0.51 release shows they are working on finding and fixing some of these problems, it has a long way to go. Microsoft had problems for years with IIS. IIS 5 was a perfect example of how commercial software gets it wrong by letting their marketing people design the system, but IIS 6 is rock solid. It's out for over a year and a half now without a single vulnerability being found. If making your software secure is a priority, it needs to be designed that way from the ground up. Using random bits of code from here or there is not going to cut it.
There's something FAR more important about security than the code, the number of eyeballs looking at it, or even the skill of those eyeballs.
Trust. More specifically doing away with Trust.
I had a minor epiphany yesterday, read about Microsoft's DRM efforts, and realizing what may be fundamentally wrong with their security. IMHO, Microsoft believes that bad security is due to bugs, and that if they can squash their bugs, they will be able to have secure code, AND be able to TRUST the computer that their code is operating on. I'll even let them consider an insecure algorithm a bug, for the sake of this discussion. I think they really believe they can eventually ship sufficiently bug-free code to be considered Trustworthy in execution.
Contrast that with the attitude toward security that has grown in the Open Source arena. No matter how good you get, bugs will *always* be found. No matter how secure you think your system is, *someone* can always get in. Finally, you have to consider *all* avenues of attack, not just the technical/cracking ones.
Some descendents of these attitudes:
Without physical control, the rest of the security is worthless.
Human engineering is probably the biggest security hole.
Consider security as a value proposition, in two ways:
1: Can I make it sufficiently expensive that they'll attack someone else, instead of me?
2: How much do I want to spend on security, and how do I balance that with a recovery plan?
Security isn't a "nail it down, once" thing, it's a process, and includes evolution.
Bugs will happen, so put security in layers, to try and eliminate single-point-of-failure issues.
It's not so much the code, or the eyeball count, or the specific eyeballs. It's the attitude.
The living have better things to do than to continue hating the dead.
He has a point, but there are some flaws in his reasoning. First of all, just because the world can examine the source code of a program, it doesn't mean that people with the necessary skills and knowledge will. However, it does happen. BSD is noticeably absent from the article and anything dealing with open source and code auditing needs to at least touch on it. (But it's dying, I know...) The author also wants us to believe that commercial software has better code auditing software and procedures than open source. He doesn't give much evidence of this, we're just supposed to accept it because they have lots of money and the impoverished open source hackers don't.
Judging from this article, I would doubt that the author has a true understanding of the open source concept. Just because something lacks structure doesn't mean that it's inferior. What really matters is how vulnerable a box is to being exploited. And in terms of real-world metrics, despite much-vaunted 'security initiatives', open source software has a better record of delivering network services more efficiently, reliably and securely than commercial alternatives.
Actually, if my experiences are any indication, most corporate development teams don't have much care for security concerns. There are several reasons.
1) Incompetence. HR departments don't know how to hire coders. They often think a degree means you know what you're doing. Portfolios are rarely asked for, likely because even if they were, the HR departments wouldn't know what the hell to do with them or how to evaluate them.
2) Time to market. Open Source does things when they're ready. Even projects with time-based releases do a "whatever is ready in that time" release, not a, "we're going to do a, b, c in this time." The rush to get to market doesn't leave a lot of time for security and bug fixing. After all, you can release a patch later, after the profit has started rolling in, right?
3) No corporate incentive. The product has a bug or security hole. Unless it becomes a big deal in the media, why bother paying programmer time to fix it? Your customers are already customers. You've already been paid. Without service contracts, fixing bugs just doesn't have any monetary incentive.
4) No programmer incentive. How many corporate programmers have any reason to put any pride into their work? None of the customers are going to know their name, think about hiring them on a side contract, etc. When software I write entirely for Free has a bug, I know my reputation is at stake, and there's a feeling of "how could I be so dumb, I have to fix this and make things right" feeling. I don't get that feeling for corporate work; if they want it fixed, they can pay me, otherwise, the bug can stay and I can get on with my life.
5) Security Through Obscurity. Why fix something nobody knows about? Not only are you not going to get money from your customers for your efforts/programmer-paychecks, you're not even going to get any PR bonuses.
There are many companies where the above don't apply. Good companies have good HR departments that bring in the other developers into the hiring process to select new employees that are actually skilled. Some companies have corporate pride and worry about quality as well as the bottom line. The above problems are not _rules_, they just common patterns I've noticed in my work, and in the work of others.
OpenBSD is secure by default because it doesn't start any services by default. Samba is just as insecure on OpenBSD as it is on any other machine (for the most part). So while the OS itself might be "secure", as soon as you install other Open Source software on top of it, you're pretty much in the same ballpark as everyone else.
I haven't read the article, but this doesn't seem to address what can be better secured. With superior firewalling, setting partitions to noexec, and BSD Jails (among many other things) an admin can make a system fairly secure even with software that has security problems, it just means that you need to know what you're doing.
Discussing "the security of open source software" is like discussing "the structural strength of green objects". There are too many projects with different goals and different team cultures.
"What approach do I pick to make $PROJECT most secure?" is a meaningful question. Even more meaningful is "What approach do I pick to make $PROJECT most trustworthy?"
Open source is the answer to both. For a security-critical application like PGP it's imperative to get multiple independent reviews from fresh perspectives. Open source is a necessary but not sufficient criterion for being able to accomplish that.
MOST bugs or flaws that lead to exploits are things that CANNOT be found by using a "structured" method.
Otherwise, you could write a tool that probes for those.
The effect would be that that class of exploit would disappear.
Usually, exploits are much trickier (chaotic, even) than that to find and are usually found "in the field" by actually using the software under a variety of conditions when all the "eyeballs" have failed.
But trying to be controversial to sell a book never hurt...
Move along, nothing to see here.
I don't know the meaning of the word 'don't' - J
I actually think the parent poster and the parent article both miss the point to some extent, though the article is closer to the mark.
Open source is not a magic bullet that will automatically solve all our security problems, as much as I advocate open source software, and open source software is not automatically more secure. The reason why this falsity perpetuates is that people tend to think of security in terms of buffer overruns instead of a secure structure. No development methodology can ensure this secure structure because it is an issue which is either solved in the design phase or not at all.
The question shouldn't be "Can this software be compromised" because you should assume that all software can be, but rather "what happens if this software is compromised." Some open source projects are very good at this, and some aren't.
It is also true that for some projects (like OpenSSL), this question is irrellevant because the primary usefulness is as a library, so the application will have no security itself. But these are the exceptions rather than the rule.
Compare the security of Sendmail (open source) to Postfix (also open source). Which is more secure by design? Compare Apache to IIS. Which is more secure by design? (IIS drops permissions after authentication, Apache does so before). Compare Sendmail's security design to IIS. Which is more secure by design?
Open source is important even from a security viewpoint as it allows us to better understand the architecture of the program we are considering and make educated choices about whether we can run it in a secure manner. However, it is no magic answer and just because something is open source does not guarantee its security.
LedgerSMB: Open source Accounting/ERP
I recently attended a web seminar (webinar) Novell hosted about SuSe Enterprise Server 9 security. They talked a lot about the security certificaitons Suse has been awarded, and how even Micrososft has not been granted the highest level of security for it's 2003 server line. They then presented a poll for the attendees, "Which is more secure open source, proprietary, or a combination of open and proprietary software"? As predicted the combination response won. I think the correct answer to which is more secure Open Source or Closed Source depends totally on what programs are being discussed and where they are applied. Remember just because the source is open doesn't mean it's audited and the people that find security holes necessarily want to fix them. With great power comes great responsibility, as Stan Lee so wisely put.
Novell said in an internal study they found that open source tends to be more secure in popular applicaitons, so Apache is more secure then IIS (as if we needed them to tell us that!), but they found out that in obscure programs proprietary tended to be more secure. This is probably the main idea behinds Novell's recently annouced both source stance. Granted they have financial reasons for not wanting to open source parts of their product line, but this rational does seem logical. Though it would offend the stallmanites.
$RantMode=on
Computer security means many things, but can be summed up simply as: The protection of the information and physical assets of a computer system.
As a reminder, this means Hardware AND Software security.
As a Real-world security geek, it appears to me that the three worst software issues are:
Please note that "Crackers hacking into your system in order to steal trade secrets" isn't even on the list.
So, no matter which of the top three you care to rant about having security issues in your software, they ALL can be solved with the same two pieces of software on either your own PC, or on a corporate side, ie: Firewall softare (set to deny all unless allowed), and any reasonably competent virus checker (Scan local drives/emails/web pages before loading to the browser)
So, the real question is not which has more bugs, closed source, or open source, but is instead "Why don't more users have those two pieces of software?"
Maybe, instead of beating each other up about security flaws in software, maybe we could all spend some small amount of our time educating the users to get these two packages, and to keep them up to date.
Imagine if a million geeks all spent an extra 15 minutes while visiting their friends and relatives to educate them about this?
$RantMode=off
LongTail SSH Brute Force analysis tool is here!
For instance, would anyone please care to elaborate on why the Parent post here is moderated as '5, Funny', while this post is moderated as '-1, Offtopic'?
The humor inherent in the two posts is quite similar. Both are quips directed at the misspelling of the word 'Security' in the submitted story under discussion. While they may differ in the specific approach taken to achieve this goal, the fact that one could be considered 'Funny', while the other is thought to be 'Offtopic' is highly inexplicable.
Logically, neither post is more 'Offtopic' than the other. They are either both 'Offtopic', or neither one is. This state of affairs is therefore quite puzzling.
Without the darkness, how would we recognize the light?
"So a product without a competitor is no different from an open source product."
Actually, it's far, far worse, as there's an immediate commercial disincentive to security development.
It costs money.
Someone may do code reviews for free or for fame on opensource, but nobody is going to review commercial proprietary closed source without a fat paycheck.
As long as there is no serious competition any money spent on security is wasted money. And once security becomes a selling point it's most likely much more cost effective to market the perception that the product is secure, rather than actually securing the product. Claim 'blah blah methods, blah blah secure, blah blah focus, blah'. Say it's all the evil hackers abusing your product because it's popular, etc.
A few marketdroids are far cheaper than having your programmers spending half their time doing code reviews.
The main advantage that OSS software has is not the eyeballs on the source code, it's the ability of the community to guide its development. There's no way for a vendor to take a disasterous wrong turn against the wishes of a broad part of their user base.
If Windows had been open source seven years ago, we would have been able to keep a version that didn't integrate IE with the desktop in use, we would have been able to come up with a clean mechanism to split the useful parts of the HTML control from the dangerous parts, and the majority of the script- and zone- based email viruses and worms that have been plaguing the computer industry for most of the past decade would never have happened, and we wouldn't be waiting for the next attack to hit their daft "security zones" train wreck.
If Apple's LaunchServices and Webkit were open source, we'd be able to split LaunchServices in two and have a separate set of bindings for internet applications, and we wouldn't be waiting for the next protocol-based attack in Safari.
"Most of time" OSS vendors don't test? Wow, way to pull that one out of your ass. Last time I checked companies like IBM, Red Hat and Novell did extensive testing of their products before they shipped them. Not even to mention projects like Apache, Postgresql, Squid, Perl, Samba etc etc. And your proof that most commercial closed source vendors do extensive testing compared to OSS vendors is where? Oh right, your ass again...
.0002 of some small project who doesn't do OSS full time. Yep your right, that's the OSS mantra *rollseyes*.
Name a hugely popular OSS vendor that shipped a buggy product and I'll name twice that number of large commercial vendors who have done the same or worse. Versions of Windows filled riddled with bugs in their "gold" version. Versions of Norton Antivirus that hose your computer if you don't run Live update immediately after installing.
"It works on my box...bug must be fixed!"
Who the hell says that? Oh right lone hacker of version
You have a totally warped perspective of how much testing and bug hunting Commecial vendors do. I've been in IT for 10 years now and if you had been doing it for at least 6 months you'd realize that commercial vendors are no saints when it comes to testing their wares before fostering them on the public and business world. For someone who claims to be from the "business world" your certainly clueless as to how it actually works.
Even if you do not believe in skills of open source community, at least you can hire your own specialist to look at possible problems in critical code. You cannot do that with closed source, you are doomed to remain a believer of code vendor.
I repeat: You CANNOT be sure you are secure with closed source, no matter what you do. You CAN secure yourself with open source, if you make effort.
There you are, staring at me again.
Nah, this only works if you have a monopoly lock-in. Sure, you're also kind of locked in if you just spent $20,000 on a software package you don't wanna throw away but that's full of bugs. Still, this will destroy your reputation and do you no good in the end.
The golden rule of business is to make your customers goals your own goals, because long-lasting relationships are essential to your own long-term success.
Despite what the "religious fanatics" believe, how secure a program is is not whether it is open source or closed source.
It is more dependent on the programmer AND the person configuring it. Look at PHPNuke. Look at djbdns.
Thinking that many eyes can spot security problems is like thinking that a million monkeys can type out Shakespeare.
You need skills and experience, eyes are just a useful option.
The difference lies not in the number of vulnerabilities. All software, open or closed source, will have holes in it. That'll be the case until we have a system in place to write completely bug-free code and a system to insure vulnerability-free specifications (the worst security problems aren't bugs, they're design features which favor convenience over security). The difference lies in what happens when a vulnerability is discovered. In closed-source software, we've seen time and time again that the response by the vendor is almost always to conceal the problem and deny it exists. In open-source software, by contrast, vulnerabilities are almost always published fairly quickly and fixes made available rapidly. That's because nobody is at the mercy of the original author for a fix. The people who discovered the problem can publish a code fix along with the details of the problem. People affected by the problem can patch the code themselves, if it's important enough.
In addition, security holes by design tend to get eliminated from open-source software. In proprietary software, if an insecure design feature benefits the vendor it's unlikely to be removed short of open revolt by the users. In open-source software if there's another way to do it that provides less security exposure and the original author won't change the design, someone else tends to get fed up, make the change and make the patch available. Eventually the original author either has to bow to user preference or find his own version of the software being ignored in favor of one that does.
I was struck by something while reading this passage:
Not only is that sort of developer not looking for security bugs, but they're pretty likely to be just getting their feet wet working on that project and might well introduce a bug. Then, there's a significant possibility that nobody else cares about the feature that one developer added to scratch their own itch, so nobody's going to look at the code that implements it. Yes, there are more eyeballs, but those eyeballs are not evenly distributed. There are certain pieces of code that everybody is looking at, and there are vast tracts of code that practically nobody is looking at - none with an eye toward security. How many Linux drivers have you looked at? I'll bet the majority of the people reading this haven't really looked at any Linux kernel/driver code whatsoever. Have you looked at the code for Apache? Perl/Python/Ruby? MySQL? Gcc? Open-source users outnumber programmers a hundred to one, and each developer has a fairly narrow area that they're either interested in looking at or qualified to look at, so the number of eyeballs on some piece of code implementing an unpopular feature in a popular package is nowhere near what some people seem to think. It might be dozens, it might be one, and quite often it will be zero once the guy who wrote it moved on to something else. That's no better than the almost-always-one you'll get with commercial software, and sometimes it's worse.
Slashdot - News for Herds. Stuff that Splatters.
So many of these articles that criticize FOSS from the corporate point of view are missing the real key which is that FOSS doesn't need them, it's quite the opposite. Adopting FOSS is like offshoring. It's not like China and India are pleading with all these multinational companies to come and set up shop and out of humanitarian brotherly love they decided to go. No, they're going there to save bucks --AKA the bottom line.
Same with open source. It's not like companies switch because they're doing a favor to open source. They have no position to criticize because they're coming begging. These are not friends looking to join in and contribute, these are simply corporate accounting offices saying cut costs --now damnit! They're using open source to save money and then we get twits like this guy whining about the deal.
For many home users, security is a non issue. Take me for instance. I have backups of all my documents and I don't care if people read them. The rest is just media and open source. Why do I care if somebody else sees these things? I got them for free, if somebody gets a copy it doesn't bother me a bit.
Sure, I don't want somebody to use up all my bandwidth sending spam, but that doesn't happen. That's about the extent to which I'm concerned about security and that's about the extent to which open source software takes care of my needs.
So, for a home user like me there is no security problem. As long as all my apps work and my net connection is smooth I'm good to go. I have no need for water tight security.
Now we get this corporate droid coming up with his theory that FOSS lacks security. Alright, then if that's the problem then his corporation shouldn't use it. He's absolutely right. Don't use it dude. It's too dangerous for you. You should have your company pay everything you can to MS or Sun. Meanwhile, his competitors who figure out how to make it work will have lower overhead and eventually whiners like this will be gone. It's a self healing problem.
We all know he's wrong. The evidence against closed source is so daming it's insane. I hear people talking about people booting up with a LiveCD. Well duh. If you have access to the console no system is safe. This is nothin' but FUD. The real question is who owes this guy and his type anything? Instead of whining, perhaps he should join a security project if he's so concerned. But he's not really concerned at all. He's just looking for attention.
If you look for them in a structured way, then you only find the ones that your structure is looking for ;)
This isn't even close to being true. Why are you spreading this misinformation? Serious security problems in large open source projects are very competitive with smaller projects in their bug fix and turn around. Nearly every majory security problem is fixed the day it hits the media. Most often when
There may be exceptions, but they are rare.
Sigs are awesome huh?
...but he does not believe those eyeballs are looking for security problems in a structured way.
As a developer of proprietary software (hey, no flames, it's my job), I can assure you that there is very little structured security analysis of closed source software. Some closed software may be rigorously audited because of its nature, but the same holds true in Open Source (OpenBSD). You're not going to see any security audits for non-security software. You might see a few half-hearted attempts at it (like Microsoft's month long fix-fest), and very localized panic attacks when vulnerabilities are made public, but for the most part it's an ignored area of development.
"Security through obscurity" is still king, because the people making software security decisions in commercial firms generally don't know any other way. They also do not see the financial value in secure software, because it's not something that the customer will pay extra for in non-security related software. Then there's the problem of ignorant coders.
We have all gone through the phase where we think we know about security and encryption. In a proprietary environment such a security ignoramus can reach chief software architect level. In my own work I've seen three "clever" encryption schemes by senior developers that were complete jokes. One scheme even produced *sequential* keys it was so bad. In the Open Source community such security hubris is slapped down quickly.
In short, the author is wrong. Open Source is not inherently more secure than proprietary software, but the open development model encourages a higher level of security analysis.
Don't blame me, I didn't vote for either of them!
There is the commonly held position that many F/OSS projects get source patches out the doro very quickly.
r -in-cvs to the time it takes for something tos how up on windows update.
That's true.
One problem with this is people compare the time-to-released-source-patch-on-a-mailing-list-o
I don't think that's fair for the following reasons:
1) Patch Quality.
It is clear that the volume of basic testing done on many instant-turn-around source patches is zero.
Comparatively, as often as an MS patch manages to break something somewhere, consider how much worse it would be if there weren't a few days of targeted regression testing being done. The official recommendation from MS is to test patches before putting them into production, but there have been a relatively low number of patch recalls from MS.
Finally, i think it bears mentioning that with F/OSS, the initial patch is sometimes re-written over the course of several days until something proper actually is agreed upon and that's the code that actually ends up living with the product.
So i'd consider these source level patches to very often be of "here is something that appears to close the hole and not break anything i tried, good luck!" quality.
2) Patch Applicability
When a hole is discovered in apache, the time it took for an apache developer to submit a source diff is NOT the same deliverable as what you're getting from a commercial vendor patch. A source level patch only does me any good if i am running a source-built tarball in production, and i am relatively current with whatever source base the patch is applied against, and i can handle the manual patch/compile/make install process (and if something goes wrong, i've got to backout the patch and compile/make install _again_)
Most people, especially running production machines, are not running built-from-source software. You install Redhat. You want apache ? You use the redhat apache package. You now need to wait for the updated redhat apache package to get the bugfix, or, you get the latest cvs snap and build from source. Now you've got a lovely problem because the way redhat (or any distro) builds apache is different from the defaults, so you have to go and figure out how your distro likes to build its packages, OR, you need to accept the build defaults and rebase your config files to the new settings.
So really, the vendor binary package is what many people need to wait for before they can truly patch thier machines. THe source diff is nice, but not something they can easily consume
I think between these two points, it's pretty unfair to compare time-to-patch between MS and someone-posted-a-diff-somewhere.
I think if you look at the time from vuln report to updated binary tarball being released by some of the linux distros, you'll be surprised.
My opinions are my own, and do not necessarily represent those of my employer.
I think people have to forget about the cliche that all open source software is developed by some kid in his attic. A lot of OSS is developed using the same control process as commercial software, _but_ as an extra the source code is open. I can't see how in these cases it can be worse? Of course there are and always be OSS project made just for fun or out of an itch and perhaps in these cases the article could have a point (although i don't agree, as small project with little developers can take advantage of the 'many eyeball' idea, and people _do_ look).
On a long enough timeline, the survival rate for everyone drops to zero.
Seriously ... computer security is getting lots of windbags their 15 minutes. Resist it! All that matters is that holes are being fixed at an acceptable rate in Linux, Apache, Firefox, IE, Windows, etc.
I see plenty of poorly designed and difficult to maintain software, but ofte this is NOT a business problem. The problem is that some engineer muffed up the design or analysis and didn't realize it until it was too late to start over. As much as I'd like to rewrite much of the software I have to work on, the fact is if I'm going to get paid, the software has to make a profit, which means I can't go rewriting just because it isn't a elegant as it could be.
Sure it rubs me the wrong way every time I have to look at it, but if it will make more money as it is than if I took the time to rewrite it, it won't be rewritten.
Besides, I have a strong suspision that if all commercial software was beautifully engineered we would not have open source software. Ugly commercial code developed under tight deadlines is, I think, one of the primary reasons may developers write open source projects, because thats where they have the freedom to do it right, without worrying about project costs or deadlines.
But I'll sum it up in a few lines.
According to him, there may be "more eyeballs" looking at open source software
More eyes looking at something means more chances of finding problems, dumbass.
but he does not believe those eyeballs are looking for security problems in a structured way."
As compared to the fantastic job some structured companies have done?
BTW, you'll note that the worm authors do not have any sort of gigantic megacorporation providing them with "structure", but you'll notice that they seem to find security holes to exploit just fine.
To sum up: Viega is a moron.
Weaselmancer
rediculous.
I just learned that the lock on the front door of my house has been broken since the house was built. Even though I turn the key when I leave, anyone can turn the knob, walk in and steal my computer. I've been lucky -- nobody's stolen my computer.
Should I fix the lock? Should I buy a another lock from the same vendor? Is my house secure because nobody's tried to break in? Based on results, the house is secure.
I'm getting a new lock.
You know, I have mouths to feed. I try to do it "the right way" instead of "good enough", but at times the client *demands* something and if they *choose* to be stupid after being explained what's problematic about their ideas, well so be it. You don't throw your job away these days, and if the job is fun enough most of the time, I don't mind about stupid clients. I told them, they insist, they get what they deserve. If I have to change it later, great, I'll happily charge for the extra work.
Who is General Failure and why is he reading my hard disk?