« Previous article — Next article »

The state of code signing in Open Source

March 20th, 2009 Posted by D Webber

Time for an update.  A while ago I looked at which leading open source projects sign their releases with strong cryptographic signatures using GPG or PGP.

I revisted each project to see if anything had changed, and also surveyed a few more popular ones:This time there are twenty projects in the survey, including popular application software:

Apache HTTPd ✔ Individual GnuPG signatures
MySQL community edition ✔ Individual GnuPG signatures
ISC BIND DNS server ✔ Individual GnuPG signatures
Redhat Enterprise ISOs ✘ unsigned MD5SUM only
CentOS Linux ISOs ✔ Signed MD5SUM and SHA1 files
Debian Linux ISOs ✔ Signed MD5 and SHA1 files
Ubuntu Linux ISOs ✔ Signed MD5SUM file
Fedora Linux ISOs ✔ Signed SHA1 checksums
Novell OpenSUSE Linux ISOs ✔ Individual GnuPG signatures (but you have to hunt for them… see below)
Perl source code ✘ unsigned MD5SUMs only
Python source code ✔ Individual GnuPG signatures
PHP ✘ unsigned MD5SUMs only
GNU CC (GCC) compilers ✔ Individual GnuPG signatures (but not on all mirrors)
OpenSSH ✔ Individual GnuPG signatures
Netfilter iptables packet filter ✔ Individual GnuPG signatures
OpenOffice.org ✘ unsigned MD5SUMs only (though the setup EXE for Windows is signed)
Drupal CMS ✘ no validation of any kind
Joomla CMS ✘ No validation of any kind
WordPress CMS ✘ No validation of any kind
SugarCRM ✘ No validation of any kind

I couldn’t find any mention of GPG signatures on the OpenSUSE web site, but they exist if you manually edit the URL of a download site to get a directory listing (e.g. visit http://download.opensuse.org/distribution/11.1/iso/).

Why does signing matter? Much of the world’s business is conducted using these and other Open Source software projects, including e-commerce sites, banks, government and the military. A back door or other compromise would have a far reaching impact. And it has happened:

Even when central project servers are protected, most projects use multiple download mirrors around the world, mostly provided by universities and volunteers and with varying levels of security. Without signed files there’s no assurance files on the the mirror have not been altered.

This happened to then Debian project several times. Fortunately, they sign their files so cleanup the efforts were straightforward. Can the same be said of PHP, Perl or the three most popular content management systems? Imagine the money you could make sneaking a backdoor into any of those.

Of course, secret source projects are not necessarily any better. Anyone remember when Microsoft’s network was compromised? Intruders rummaged around their network for three months and managed to leak (though, we’re told, not alter) source code of Windows and Office.

Commercial vendors benefit from the assumption that their development and release processes are better. Yet we see from the post-mortems of every card data and privacy breach that having a bottom line often results in worse security, not better. I’ve audited several commercial organizations who had appalling development practices. Even when good controls exist, those inconvenient security thingies are often the first to go when a release deadline approaches or costs rise.

Signing files isn’t a panacea. The whole development process needs to address integrity of the code. But signing files is not hard. At the very least it mitigates the weakness of using miscellaneous mirror sites to distribute files. It also kills one argument used by secret source proponents to spread fear, uncertainty and doubt.

Related posts:

Posted in Best practices |
Tags: , , , , ,

Comments for this article are closed.