Heartbleed and the misconceptions about Open Source
binpress.com
binpress.com
It's important to discuss what changes we can (and should) make to make problems like heartbleed less likely in the future, but wildly waving competing generalizations in the air doesn't help anything.
This is absolutely BS, especially in security and cryptography. Most security related code written by most so-called "professional" software developers is astonishingly terrible (e.g. ECB mode encryption, storing encryption key in code, reusing encryption keys, relying on (unauthenticated) encryption for authenticity, reusing IVs, linear time MAC verification, ...). Most cryptographers are academics. Also, anecdotally, the poisonous "demo an exploit or it doesn't happen" attitude in response to hints at a flawed system design is much more prevalent among "professional software developers" than in academia.
If anything, we should encourage more security experts in academia to engage in implementation, verification, and improvement of security code, not the other way around.
(Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
I don't see why an OpenSSL developer would need either of the first two skillsets at all. Ideally, yes, but not necessarily.
[1]: http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipse...
[2]: http://www.sandelman.ottawa.on.ca/ipsec/1995/04/msg00148.htm...
Your main case there is software developers failing to do protocol design, which is exactly what I'm saying is a bad idea if they don't happen to be independently expert in it.
The reality is these situations would be a whole lot easier to resolve if people actually respected the expertise of each other. This works in all directions, but recent bugs show a definite weakness in terms of respect given towards relatively basic software engineering practices.
Certainly it helps to have a minimum of appreciation of the other parts of the domain, but I think you greatly overestimate how important that is for the kinds of problem we've been seeing lately.
It's possible that more vulnerabilities are caused by programming errors than by protocol misimplementation, but the latter do happen and are just as bad.
Security experts write bad code. Non-security experts write bad code. Code, by default, should be assumed to be bad -- you're right far more often than you are wrong. That's why stringent review and re-review of code (both at the micro and macro level) are required to actually end up with a decently secure product.
I'm a huge fan of setting up adversarial teams for this. If you have two product teams in a company, have each team breaking the other's product; the closer you are to something, the less likely you are to see the bugs, so this model works phenomenally.
In my experience, security training (even up to the level of expert) helps people write better code only in terms of the most low-hanging fruit (SQLi, CSRF, basic XSS). But due to how close the author is to the code, it's nigh impossible for them to see the really bad bugs. But if you train your developers to break things and then point them at other teams' products, you're going to end up with a far more secure company.
An example: "anyone can contribute, regardless of background or proficiency". I'd encourage the author to research how open source projects are run before making claims like this.
Also.. How was this bug found again? Oh yeah. By analyzing the _open_ source code.
Professionalism is orthogonal to open source vs. closed source. There's a place for both, and there is good and bad open source and closed source software.
Moving right along nothing to see here.
It was found by fuzzing. OpenSSL being open has absolutely nothing to do with its security, in a positive or negative way. It's just a poor project.
I also love how the author puts a thinly-veiled plug of his slimy "open-source" code-selling website in the middle. As benatkin said in his excellent comment [0], all four of their featured products are closed-source. The OSI should sue them for violation of their trademark of the term "open source".
patches and added features need to be reviewed by project owners.
open source mostly mean "you can read the source and modify your version, but that doesn't mean you can make a change that will go into the official release."
There are some very sensitive implementations of software which should be thoroughly examined by experts and criticized if they're not good enough. If there is no resources available to maintain a particular open source software, don't bother use it, ESPECIALLY if it's sensitive like openssl.
Open source allows software companies and other programmers to easily work together to solve a problem. Developer's time is precious so it's often time-saving to use somebody's else work, but that doesn't mean you should use it blindly.
> open source doesn't necessarily mean "anyone can edit it and improve it".
I think you missed the point in the article - it was about how anyone can create or contribute to open-source. Not about submitting patches to existing projects and have them pulled upstream without any review process.
You can look at the frequency of patches between proprietary and open source software, which shows a lot.
If you don't have the source code, it's actually a little harder to find a vulnerability since all you have is a big blob of binary assembly. Hackers can still find vulnerabilities with enough time on their hand, but it's still much discouraging.
No free lunch in security rather hides in the trade-off with convenience.
i'd rather say "and you just don't know about the closed source ones because they're harder to find" ;-)
This particular observation comes up any time something goes wrong in any context. The stuff about the shallowness of bugs really has nothing to do with the argument. This bug was in fact quite shallow, some random entity just found it by looking. If more people had of been looking then it would of likely been found sooner. You can only find a bug once.
So I don't think they are in a good position to be talking about the meaning of Open Source, as they're doing in this article.
I don't think it's that surprising that our most popular projects use our own licenses instead of FOSS licenses. Most people care about results and access to the code, and not whether the license was generated by the OSI or the FSF. You can go over our licenses and provide commentary if you feel the need to do so - but please don't accuse us of doing something we don't.
Open Source is a made-up word. It did not exist before the OSI used it to promote OSI approved licenses.
With that out of the way I fount at least one non-open source product: http://www.binpress.com/app/pdftouch-sdk-for-ios/859 The licenses is almost 100% non-open source: http://www.binpress.com/license/read/id/1565/app/859 The only Open Source like-clause is the non-expiration!
The OSI trademarked the term Open Source to avoid confusions just like this. Not allowing redistribution is BIG difference! Not only is BBpress selling proprietary software, its diluting the very meaning of Open Source!
The one you linked to only allows binary distribution. This is how those projects support themselves, by offering tiers of pricing depending on the user needs. We just require that at least one of the licenses allows redistribution of the source. So I'm understanding that by your world-view, Open-Core projects are not open-source? or that open-source can only be used if sanctioned by the OSI? I'm afraid that no one has monopoly on that term. It means different things to different people. We call our products "Commercial open-source", which you can find the usage of which on the web and wikipedia as well. Most projects on GitHub do not have a license, which means they are copyrighted by default. We vet licensing for each project on our site, to make sure there are no copyright or licensing breaches, and provide a range of licensing options to fit the developer POV. Not sure where all the hate is coming from.
Another good portion of the hate comes from the fact that you're selling projects that are not open-source as open-source.
Maybe it's just me, but if you're running a slimy code-selling website you should at least know better than to call it open-source. Here's a link you should read before you get sued by the OSI, which I will be kind enough to not charge $750 for: http://opensource.org/docs/osd
I'm also curious why you think integrating a PDF reader into your app costs $36k. In my world we just use a UIWebView. Or, if you want to type maybe five more lines of code, you can use CoreGraphics. You can then spend the $36k you save to get Donald Trump to fire your horrible developers.
Finally, you probably want to fix the grammatical issues in your laughable "commercial open-source" license if that's a core part of your business.
My issue is 100% the association of the word Open Source with proprietary software. Yes, even the enterprise license is proprietary. I think we have a big issue in the software world with confusion about what makes something open source. Part of this is because web software skirts the GPL and so some people have come to see Open Source as for the benefit of the developer.
Open Source is about the user. It is about giving the user freedoms, not saving developers money.
Now, the enterprise license is interesting. It is better than the introduction licenses and I think is 90% to the four freedoms. The only thing is the requirement to only distribute modified source. Which is a weird requirement since one need only add a no-op.
If I was running BinPress I'd inverse things. iOS devs and devs of proprietary software do not want to make their software open source, so charge them for the ability to use your library without distributing their code. This is the dual license business model and it can work well. Propreitary software has the money so get them to finance the open source project.
As far as I am concerned if you are not distributing source and redist rights to end-users then you are worth only as much as you can finance real open source.
Edit: I would also like to mention that I did not downvote pytrin.
We are also in touch with the OSI for creating a 100% open-source compatible license of our own that could be officially sponsored by them. It's been a slow process, but we hope to get it done in the near future. Our own license was created with the help of copyright lawyer that has dedicated his professional life to supporting and advocating open-source. It is a compromise between closed-source / commercial and fully open-source (what we call "commercial open-source"). For many purposes, it is less restrictive than the GPL (no stipulation on releasing your source if you modify and distribute on other formats), which makes it more attractive to businesses building commercial products (for example, iOS application, which cannot use GPL).
Hope that makes sense!
Sir, I must say, being on HN, you are at the outright wrong place!
This is almost a non-sequitor (Sp?). Almost none of those software engineers looked at the source (and those few that did got eye bleed).
I quit reading after that.
There are fundamental differences between bugs and security holes. Bugs are something everyone has an interest in fixing. If a bug rarely manifests itself - then it is not that much of a problem.
Security holes are things which some people scrupulously search for, and then sometimes keep secret, for their own ends. Sometimes people even try to create security holes where there are none ( http://lwn.net/Articles/57135 ).
Open Source gives you potential to build a rocket to the moon. But it requires money and time and people willing to mind the code, and people with humble attitudes willing to accept when they've made mistakes and patch the code.
Quality Assurance requires effort, and that's where the fallacy of "Free" software really comes from. If you're not paying for it, you're going to pay for it. (Either by being the QE team and fixing bugs yourself or by living with buggy software.)
The article wasn't particularly good, which may explain that.
> …that's where the fallacy of "Free" software really comes from. If you're not paying for it, you're going to pay for it.
The "Free" in "Free Software" has never meant "No Cost". It has always meant "Freedom". When you start talking about cost you are missing the point.
So it's not that you think the article isn't very good but instead it just isn't? Bold statements like this need an explanation...
Stating that the article isn't very good and using it as an explanation as to why someone's comment was downvoted without giving any reasons does not really contribute to the discussion and also does not prove your point. Just because awalton has a different opinion does not mean that he/she is wrong.
First off, everything I say is "according to my opinion". That is implied and I don't have to explicitly state it on every sentence I write (especially on sentences that already sound like opinions).
Second, it's really not a bold statement. Read the other comments here—quite a lot of them are critical and the top rated ones all have excellent points. Given that, claiming the article isn't very good isn't much of a stretch. You want reasons? Read the rest of the %$#@! comments.
Now, my comment may have been on the pithy side, but I found it particularly funny that the guy was commenting about how he agreed with the article, complaining that when he expresses the same sentiment on HN he gets downvoted, but nearly every other comment on the story was attacking its shallow understanding of Free Software/Open Source, cryptographic library programmers, and virtually every other point it tried to make. IE, he appears to have same misguided opinions as the article's author, but not the self awareness to enlighten himself.
Thus, Binpress always looks to combine their one very good point (that better funding for Open Source is important) with a bunch of junk trying to say that buying their proprietary software is the answer.
Only by moving crypto functions to a separate user maintainable black box will this tide ever be stemmed. Of course, verifying that black box then becomes problematic, but it would be easier than the current situation.
There is a verified optimizing C compiler, CompCert. Admittedly, it is not gcc, and it is not easy to do, but still. Writing a verified SSL implementation is probably not more difficult than that.
Also, verification isn't a magic bullet, you need a good spec.
Total market cap of the top three tech companies is more than a trillion dollars. Even a hundred times more resources is affordable for them given the criticality of the project. The replacement does not have to be written in C, it can be written in ML-like languages and expose an external C interface.
> Also, verification isn't a magic bullet, you need a good spec.
True, but drawing from the CompCert anecdote, I suspect bugs in a verified implementation would be orders of magnitude less likely.