Slashdot Mirror
Free Can Make You Bleed: the Underresourced Open Source
jones_supa (887896) writes "After the Heartbleed fiasco, John Walsh brings attention to the lack of proper manpower and funding to run various open source projects. Free is not usually a bad thing, but it can be when it causes the software your business depends on to be under resourced. 'OpenSSL for example is largely staffed by one fulltime developer and a number of part-time volunteer developers. The total labor pool for OpenSSL maybe adds up to two fulltime developers. Think about it, OpenSSL only has two people to write, maintain, test, and review 500,000 lines of business critical code. Half of these developers have other things to do.' Theo de Raadt has also spoken about too much donations coming from the little people instead of companies, and not too long ago even the OpenBSD project almost couldn't pay its power bills. Walsh goes on to ponder security of open source software, the 'many eyes' phenomenon, dedicating people to review code, and quality control."
If your business relies "critically" in its functions on such a piece of software, how would you as a business owner ensure the continuity of the "critical" function?
A. Hire someone to maintain and work on that software.
B. Whine about someone not giving you their time for free.
C. Buy a commercial solution which costs you 50 k USD a year and has at most same level of support as OpenSSL (though better packaged and you get to chat with the smooth sales rep)
What do you do?
From a bit different perspective (largely unix-practical) -- when not having enough resources, you are forced to keep stuff simple. That's usually good, isn't it?
Anyway, I always wondered why is OpenSSL such a bloated pile of code. It does one god damn gazillion things tightly packed. Now, TLS implementation itself is pretty simple, Key management tools are pretty simple, PKCS verification tools are pretty simple, mathematics behind that is pretty simple, commandline tools for quickusing the maths are simple, relationship between those entities ("APIs") are well-defined and usually clear. Who stuffed all of it into one project?!
PS. Bonus paranoia&FUD I saw today: http://pastebin.com/gjkivAf3
The author works for the actual SSH company that sells commercial SSH software. Though the points may largely be valid, a lot of the slant in the article is meant to tell people "this is what happens when you don't pay for software, so buy our commercial stuff today. Because it can't POSSIBLY suffer from the same kind of mistake, right? Right guys? ...guys?"
SSH programmers make mistakes. The article writer has an agenda and it's quite obvious. There is no reason to assume SSH is of any better quality than OpenSSH. He even shoots his implication in the foot: "are you going to review two year old patches for errors? No, of course not." This is no different in paid software. If it gets missed during any sort of review, the hole remains. See the recent IE 0-day hole (which has only been around for over a decade) for proof that this is true.
If your business is depending *critically* on a piece of free software then don't be such a cheapass git. Hire a developer or allocate some of your budget to fund the project.
Problem solved.
SJW n. One who posts facts.
How many programmers does Microsoft have? Are their products bug free as a result?
In some cases, fragmentation is bad. In case of critical infrastructure, fragmentation is great!
Having multiple interoperating implementations has been always one of the basic requirements for internet standards, it ensures future growth and leaving out the worst warts, dependency on undocumented behavior etc. But most importantly, if a bug is found in one of the implementations, it cannot take out the complete internet infrastructure because large parts of it are running a different implementation. Even if a bug is found on a protocol level, some implementations may not implement that feature or implement it slightly differently and aren't involved. Fragmentation is essential to the robustness of internet.
It's not the fall that kills you. It's the sudden stop at the end. -Douglas Adams
The problem is that with "many eyes" all the eyes are assuming some other eyes are looking.
Free is not usually a bad thing, but it can be when it causes the software your business depends on to be under resourced.
Of course, paying money for closed source software is no guarantee that it's going to be adequately resourced either. Compare the two most recent, high-profile flaws, both very similar, in that they deal with memory allocation issues:
- Heartbleed on SSL has a team of 2, was extant for 2 years, was patched in 6 days, and the patch was available to anyone who used the software
- CVE-2014-1776 on Internet Explorer. Don't know how many people the team, was extant for 13 years, was patched in 6 days, and the patch was originally going to be denied to users who hadn't upgraded recently.
This does not seem to be an issue with closed vs open source development models - both have had major vulnerabilities extand for far too long, and both can turn around fairly rapid patches when needed. Doling out cash to Microsoft is no more effective at securing your applications than using free open source products.
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
The problem is not that the software is free (as in open). The problem is that people (and companies even more) perceive it as free (as in beer). That that's the main misconception.
Companies want to cut corners by using OSS. They don't do it because it's easier to review, easier to adapt or easier to find someone who can audit it sensibly. They want it because they can grab it and use it without having to pay anyone for it.
And that simply won't fly. Because that entails the "can't someone else do it?" attitude. Yeah, the code should be reviewed. But someone else will do that, we needn't spend money on that. And it should be audited, but can't someone else do it and we save some money?
Funny enough, the fact that anyone can review, audit and fix things is also the reason why nobody does it. It's a bit like that job in your company that anyone could do, and since anyone can do it, everyone relies that someone else will. There's so many who can, at least ONE of them will. Right? RIGHT?
And since the fact that it is "cost neutral" (to avoid saying the ambigious free) is one of the criteria, if not actually THE criterion, why an OSS product is chosen 999 out of 1000 times in a corporation environment, you may rest assured that the same cheapskates that chose OSS because they can pinch a penny will not spend it on auditing it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
....the 'many eyes' phenomenon,....
And nobody reviews the source code. People download, use the library/code or whatever and be on their merry way.
This "you can't get anything bad through because the source is freely available" has proven to be horseshit.
Some people are under the assumption if you release something open source, you will get hundreds of volunteers lining up to work on it. And when they do, they will work on EVERYTHING. Truth is unless your project is "sexy" it's hard to get developers. Look at Linux kernel, a lot of the development is done by paid developers (not a lot sexy about the kernel). Look at where projects spend their focus: Firefox reinventing the UI again, Compiz Wobbly windows, usually any application that can be skinned, has 400 skins for every useful plugin. Meanwhile things like performance, or user documentation gets neglected.
Don't get me wrong, I think there's benefits to Open Soruce development models, I just don't think open sourcing something means hundreds of people are looking at it.
But you do get a "lot less bad though". Compare open source to closed source and compare the problems and the number of those problems. Close source security problems lead the way by a long margin.
No system is perfect but open source is closer to that ideal than closed source.
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
One follows from the other. If your Free license says that anybody that works on your product is required to give away their efforts for free-beer free, it should not be surprising that it's difficult to find companies to spend money on something (like paying a developer) that won't give them a competitive advantage. This, incidentally, is why we have taxes; it forces people (and companies) to pay for the common good. We wouldn't have much in the way of public works if they relied solely on charitable donations and user fees.
This is a persistent weakness of Free software, but you'll never get RMS to admit that money to pay for programmers does not magically fall from the sky. People are cheap, and if they can get something for free, it's no shock that few of them will pay for it.
In my mind, an ideal software license would have the following;
1) Mandatory Code Release (This gives you some software Freedom)
2) Payment required to copy and/or use the software.
3) Some sort of revenue sharing scheme so that any contributors to the code receive a portion of the funds collected.
Think of it like a "software co-op license"
(This, incidentally, is how industry standards commonly work in the hardware business. You want to implement the IEEE 1234.567 standard? You pay up a standard fee per implementation, and that's doled out to the contributing companies.)
Understaffed to save money with a huge backlog, insane deadlines, cut corners, and massive scope creep. So what's his point?
putting the 'B' in LGBTQ+
That assumes it's not possible to get software right. For a small enough code base (and 500k lines of code it pretty small), that's simply not true. The most robust solution is a monoculture around a bug-free product.
The problem is that getting there takes a lot of manpower for some pretty boring work, and that takes funding. But the funding required is pretty trivial on the scale of the companies who depend on OpenSLL. This is the kind of product where Google et al should fund hiring every security expert that there is in the world to independently crawl the code, fizz test, all the usual tricks. Then offer a $1 million bug bounty. Same for SSH. It's pathetic that we can't get this basic plumbic right, when it's just a matter of resources, and damn cheap on the scale of the companies to which it matters.
If we has an NSA that actually did it's original, defensive job we'd have this done already at taxpayer expense (and money well spent, for once), but we see that's simply not possible, so it's up to the private sector to step up.
Socialism: a lie told by totalitarians and believed by fools.