Github supports signing commits with a PGP key.
We have an open source project, that accepts contributors from people without PGP keys. Security is essential for us, and so we decided that each person who merges pull requests will sign the merges with his PGP key, and so each actual commit will either be directly signed by the author, and/or by the merger.
What is the best way to setup a continous integration build that makes sure this actually happens? We want the build to fail, alarms to go off, and possibly the commit/merge reverted, if anyone commits or merges code into the main repo, without signing it with a PGP key from a given list of authorized keys.
We are using github, so I wonder is github hooks may help. I believe we're using Jenkins for CI, however that probablly doesn't matter as it's going to be a custom script.
To clarify: The project accepts contributions from open source developers, and we won't require each of these to have a PGP key. However, each of the people with merge rights in github must have a PGP key, and the build I propose will verify this. The merge-commits themselves are going to be PGP-signed, even if not every commit is.
Update (April 2021):
See "Flag unsigned commits with vigilant mode":
To improve security and confidence in the authenticity of your contributions, you can flag commits and tags on GitHub.com that are attributed to you but not signed by you.
With vigilant mode enabled (now available in beta), unsigned commits attributed to you are flagged with an Unverified badge.
This can alert you and others to potential issues with authenticity.The author and committer of a Git commit can easily be spoofed.
For example, someone can push a commit that claims to be from you, but isn’t. > Like showing a passport, committers can increase trust in their commits by signing them with a GPG or S/MIME key.And now, when you enable vigilant mode, commits will be flagged if they’re attributed to you but not signed by you.
This raises attention if someone tries to spoof your identity as a committer or author. With vigilant mode enabled, all of your commits and tags are marked with one of three verification statuses: Verified, Partially verified, or Unverified.Try it yourself!
First, check out how to automatically sign your commits.
Then, enable vigilant mode in your account settings:Be sure to enable vigilant mode after you start signing your commits and tags.
Once you enable it, any unsigned commits or tags that you push to GitHub.com will be marked "Unverified," including past commits.Learn more about vigilant mode.
Update (April 2016)
See "GitHub GPG signature verification":
starting today GitHub will show you when commits and tags are signed.
When you view a signed commit or tag, you will see a badge indicating if the signature could be verified using any of the contributor's GPG keys uploaded to GitHub.
You can upload your GPG keys by visiting the keys settings page.
Original answer (June 2014)
From your edit, you went with option 2 in the paper "A Git Horror Story: Repository Integrity With Signed Commits":
Option #2 is as simple as passing the
-S
argument togit merge
.
If the merge is a fast-forward (that is, all commits can simply be applied atop of HEAD without any need for merging), then you would need to use the--no-ff
option to force a merge commit.
Then making a signed request-pull (which can be always signed if commit.gpgsign
is set) can limit the signing part to the commits that will be merged as contribution-commits only (as opposed to any random merge between two branches).
More details on that process on:
So if your continuous integration build only merges request-pull (used in this test script), you can check if those specific commits are signed (and don't merge them if they are not).
This script is an example of such a check: "check-commit-signature
".
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With