{"id":23932,"date":"2014-06-14T09:40:34","date_gmt":"2014-06-14T13:40:34","guid":{"rendered":"http:\/\/www.opensource.im\/?p=23932"},"modified":"2014-06-14T09:40:34","modified_gmt":"2014-06-14T13:40:34","slug":"security-woes-in-open-source-dont-believe-the-hype","status":"publish","type":"post","link":"https:\/\/euvolution.com\/open-source-convergence\/open-source-software\/security-woes-in-open-source-dont-believe-the-hype.php","title":{"rendered":"Security Woes in Open Source: Don&#8217;t Believe the Hype"},"content":{"rendered":"<p><p>    by John Linkous  <\/p>\n<p>    It seems like such a short time ago: the massive and pervasive    Heart Bleed vulnerability, triggered by a flaw in the OpenSSL    open source software product, left massive swaths of    confidential information  including user names and passwords    of public web services, and private encryption keys     accessible to anyone with a browser and the knowledge of how to    exploit the flaw. Of course, OpenSSLs Heart Bleed    vulnerability is not the only flaw that has recently been    discovered in open source software. Right on the heels of Heart    Bleed, vulnerabilities within two popular packages for identity    management, OAuth and OpenID, were discovered potentially    leading to compromise across a Whos Who of web properties:    Facebook, Google, Yahoo, LinkedIn, PayPal, and many more.  <\/p>\n<p>    All of these recently discovered flaws within open source    software platforms have many people asking the question: Is    open source software really safe? After all, these are    products, packages and tools that are often developed in a    highly decentralized manner, with contributors from around the    globe who generally are tied together as volunteers. There is    no HR process for open source projects contributors (other    than perhaps an evaluation of programming skills): what if    an open source developer moonlights as a carder, and inserts    malicious code or a backdoor into an open source library?    All the source code is available for anyone to see: what    prevents a malicious attacker from scanning the code for    vulnerabilities, and writing tools to exploit them? Most    open source packages are developed on a volunteer basis:    what if the package maintainers simply decide not to patch    their vulnerabilities, with no way to force them to do so?  <\/p>\n<p>    All of these questions have been raised in recent weeks across    industry media, blogs and tweets, in response to these    discovered flaws. Its made for great FUD and commentary    fodder, but how legitimate are these concerns?  <\/p>\n<p>    Fortunately, to paraphrase Mark Twain, the reports of the    insecurity of open source software are greatly exaggerated.    First, a short bit of history. Ill be the first to admit: I    was not always a fan of open source. My first experiences with    open source software were in the mid-90s, with early    distributions of Linux and its associated packages. Linux, of    course, does not mean the same thing as open source. But the    reality is that most peoples first introduction to open source    (including mine) was through that operating system or other    open source BSD-based operating systems such as OpenBSD and    NetBSD, which host thousands of open source projects through    efficient package management systems. Back then, open source    was trying to mark its territory, and its most vocal advocates    were folks like Richard Stallman and Eric S. Raymond who ranted    seemingly endlessly about the evils of commercial software, and    how code should be free (as in freedom of speech, not    necessarily as in free beer).  <\/p>\n<p>    Failing to use the correct terminology to an open source    acolyte, such as referring to the operating system as Linux    rather than GNU\/Linux, could get you neck-deep in flame war    on Usenet or IRC that might go on for days and no amount of mea    culpa would grant you quarter. In those heady days, it was a    full-blown technology holy war, and you were either all-in with    open source by contributing something to a package (code, QA    and test, documentation, etc.) and  more importantly     eschewing commercial software, or you were the enemy. While    those tactics ultimately helped open source in some ways, the    libertarian philosophical bent and all-or-nothing approach    alienated a lot of people who might have otherwise embraced    open source a lot sooner. For me, it was a frustrating time and    place for learning about open source.  <\/p>\n<p>    Fortunately, along came some vendors who worked out the kinks,    and I started to come around to appreciating the open source    way. First was Red Hat, who established the first successful    model for legitimizing open source with a real corporate face    and a cohesive distribution of Linux. Other vendors followed    suit, with distributions such as SuSe, Caldera and Debian    improving on how open source packages worked with each other    within the ecosystem of an operating system that was itself    open source. Fast-forward to today, and open source is    ubiquitous in the corporate world, standing equally alongside    commercial software. Linux distributions such as Ubuntu provide    a user experience that rivals any other OS.  <\/p>\n<p>    Apple has adopted a variant of BSD, itself an open source    operating system with thousands of open source packages, as the    foundation of its OSX. Open source packages deliver countless    foundation technology services to the enterprise, from name    resolution (bind and OpenDNS), to databases (MySQL, PostGRES,    Hadoop, and others), reporting (Jasper), and business    operations such as customer relationship management (SugarCRM).    And of course, open source owns the lions share of web    application servers and http platforms (Apache http server,    Apache Tomcat, and JBOSS). Even Microsoft, once vilified as the    antithesis of the open source community by some of its more    vocal members, is now recognizing that it needs to work with    open source and is making efforts at improving open source    package integration under new CEO Satya Nadella.  <\/p>\n<p>    So, lets take a moment and talk about some of the concerns    related to open source, and why theyre generally illegitimate:  <\/p>\n<p>    What about the people who write the code?    While its true that most open source packages are developed on    a volunteer basis, its also true that most open source project    founders and managers are passionate about their projects, and    want to see them succeed. They actually control who can  and    cannot  contribute to packages, and often will select people    they personally know and trust as contributors. Many projects    have very democratic approaches to development, and rely on    extensive peer review to ensure that their fellow developers    are developing quality code. This collegial model is something    that commercial development firms often try to emulate, because    they understand that it can result in better quality code. From    a personality perspective, while its true that the occasional    nutter is discovered in the open source community (such as Hans    Reiser), the quantity pales in comparison to bad behavior    coming out of commercial Silicon Valley companies (RadiumOne    and GitHub being only the two most recent examples).  <\/p>\n<p><!-- Auto Generated --><\/p>\n<p>Read more:<br \/>\n<a target=\"_blank\" href=\"http:\/\/www.wwpi.com\/index.php?option=com_content&view=article&id=17468:security-woes-in-open-source-dont-believe-the-hype&catid=322:ctr-exclusives&Itemid=2701741\/RK=0\/RS=vxKx_AyQy9xhQzqaUZU5UJDRQeA-\" title=\"Security Woes in Open Source: Don't Believe the Hype\">Security Woes in Open Source: Don't Believe the Hype<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p> by John Linkous It seems like such a short time ago: the massive and pervasive Heart Bleed vulnerability, triggered by a flaw in the OpenSSL open source software product, left massive swaths of confidential information including user names and passwords of public web services, and private encryption keys accessible to anyone with a browser and the knowledge of how to exploit the flaw. Of course, OpenSSLs Heart Bleed vulnerability is not the only flaw that has recently been discovered in open source software. <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-23932","post","type-post","status-publish","format-standard","hentry","category-open-source-software"],"_links":{"self":[{"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/posts\/23932"}],"collection":[{"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/comments?post=23932"}],"version-history":[{"count":0,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/posts\/23932\/revisions"}],"wp:attachment":[{"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/media?parent=23932"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/categories?post=23932"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/euvolution.com\/open-source-convergence\/wp-json\/wp\/v2\/tags?post=23932"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}