satis egitimisatis egitimitengda.pro

Open@Blog

Discussion on the state of cloud computing and open source software that helps build, manage, and deliver everything-as-a-service.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that has been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Login
Posted by on in Open Source
  • Font size: Larger Smaller
  • Hits: 6859
  • Print
  • Report this post

Open Source and Code Signing

What is code signing

 

Code signing is the application of cryptographic hashes to code. Most people sign code in order to guarantee that no one has tampered with the code since publishing, and to explicitly be able to say that specific artifact originated somewhere. Most code signing relies on trusted third parties to effectively vouch for the identity of the signer. 

 

Open Source

 

Code signing isn’t really new, even in the open source world. Most Linux distributions have been signing their packages for years. But Linux distributions are fortunate in many ways. They own everything from the kernel to user land applications, and typically a user installs most if not all software via the distributions package repositories. This means you trust a code signing key shortly after or during installation for that distribution. Linux distribution users ‘trust’ packages that are signed by the same key as their installation medium. Most don’t check to verify that the signatures match what the project proclaims, but such verification is available. 

 

Open source projects that distribute code that runs on platforms other than Linux or who use a method other than package repositories often need to offer signed code, and suddenly trust suddenly becomes an issue. How do you know that ShinySoftware that you downloaded is in fact the real package, or hasn’t been tampered with? Even if the code is signed, how do you verify that it is indeed a valid signature. 

 

Historically, individual projects have solved this by publishing hashes so that you can verify the contents. Some projects have even gone so far as to sign releases with PGP keys. (This is what most Linux distributions do as well for signing their packages). In an ideal world, those signing an artifact will have their identity well verified by others, creating a web of trust. Some even get multiple folks to sign a release. This works well for projects with a really geeky user base, but less so for the general public. 

 

CAs gonna Authenticate

 

Certificate Authorities (CAs)ty, those organizations that people trust to vet the identify of domain owners for website SSL certificates have jumped into the code signing game as well. Really, there isn’t much of a technical different between a website SSL certificate and a code signing certificate. And processes are similar - verifying any potential certificate holder’s identity is fundamentally the same. 

 

Enter the Operating Systems

 

Operating systems and even some platforms have stepped in to ‘solve’ this problem. Depending on security settings, many platforms will either refuse to run unsigned code or toss up a security warning. To the geekiest among us, the security warning is easy to dismiss because we’ve done our own job of vetting the software. That’s less true for general users though, some of whom assume that a security warning means your software is laden with a virus. 

 

From a technical perspective signing isn’t an inherently complicated task; the tools exist to easily provide signed code. But there are some logistical and cultural barriers in open source. 

 

Cultural issues

 

Many open source communities pride themselves on being egalitarian. Others care deeply about releasing source and letting anyone who wishes to repeat their exact steps to arrive at a binary that is identical to what they’ve built. The idea of a ‘signed’ binary that is somehow more official, or that the project has third party blessing for ‘official’ artifacts is disturbing. Many worry that it creates an ‘us’ and ‘them’ caste system in the community that can be divisive. 

 

Logistical issues

 

The makeup of many open source projects is indeed problematic when interacting with Certificate Authorities. Where is a project based geographically? Who has authority to speak on behalf of a project and can represent the project? Is the project a legal entity or just collection of individuals? CAs  will issue signing certificates to individuals, but then you have Bob Smith’s signing certificate rather than the Ramifordistat Project’s. 

 

What should open source do? 

 

Personally, I understand the cultural concerns, perhaps even sympathize with them. But I also see that many projects have people with the privilege of having commit access, or being part of a ‘core’ team within the project. Rarely do those designations cause concern or even alienate community; especially if the project is itself taking care of managing the health of its community. 

 

I also think about what the goal of open source projects are; often this varies from individual to individual in a project. But at the end of the day it’s an open source software project, the generally unwritten goal is to distribute software. We want people to use our software, find it useful, and hopefully even contribute back. If a good chunk of people download your software never get to the point of installing it because of warnings, that’s a problem. This gets back to caring about your community in my book. 

 

In many ways I think it’s even more important that open source sign their code, the easily available source code means that it is trivial to maliciously alter our software and end up in a situation where open source looks like the bad guy.  Additionally, platforms are becoming ever more locked down and secure, and we are rapidly reaching the point that if we expect our software to run on those platforms it’s becoming mandatory to provide signed code.

Rate this blog entry:
0
Trackback URL for this blog entry.
David Nalley is currently employed by Citrix as the Community Manager for the CloudStack project. In addition he's a long time contributor to the Fedora Project, where among other things he is currently serving on the Fedora Project Board. He's also contributed to in various forms to Cobbler, Zenoss, Opengroupware.org, OLPC Math4, and Sahana. He is a frequent speaker at Free Software conferences around the nation, and writes for a number of technical and open source media publications including Linux Pro Magazine and OpenSource.com
  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest Tuesday, 30 June 2015

Open@Citrix

Citrix supports the open source community via developer support and evangelism. We have a number of developers and evangelists that participate actively in the open source community in Apache Cloudstack, OpenStack, OpenDaylight, Xen Project and XenServer. We also conduct educational activities via the Build A Cloud events held all over the world.

Connect