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.
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!
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.)
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.
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...
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.
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.
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.
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".
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.
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 ).
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.
