The Foursquare Blog

I think the reasoning should be viewed as less of a security measure for the source tree itself, and more of a best practice. Consider it a kindness extended to your end users.

Developers who commit to a tree are often familiar with the code. Those that are truly involved in a project may read every commit that comes in. They know what the code is supposed to do, and how it works. They know who the other contributors are, and they are in the best position to spot defects, bugs, or security holes.

The end user has none of this advantage. In most cases, he doesn't even know where the source code is. He wouldn't know how to read it if he did. And he may not know a good patch from a bad one, nor have the time to figure it out.

How do you bridge this chasm? The most practical way is to have a string of GPG signatures from the developer to the end user, and make it easy for the end user to verify this.

So, the developer signs his release with his GPG key. The distro packager checks this key, builds a package, and signs that with his own GPG key. And the end user downloads the updated software with the packaging tool, which automatically verifies the package signature. A very friendly verification chain from developer to end user.

So the question is: if you're not willing to sign a tagged release of your software, should you be in charge of releasing the code to end users at all?