Menu
We use GitHub and we have a request to perform commit signing. After studying the process, it's not clear to me what problem commit signing solves. As I understand the process, there's "local source code" that gets committed to a "local repo" that gets pushed to a "remote repo". So there are three boxes, and two arrows creating a directed graph from the local source files to the remote repository. For the end user, the flows are reversed.
In the model as described, it seems like we want the authorizations to occur at the push to the remote repo; and commit signings have nearly no benefit.
The Git SCM manual, 7.4 Git Tools - Signing Your Work does not state the problem it is solving. It does tell me to hunt for the answer, however:
Everyone Must Sign
Signing tags and commits is great, but if you decide to use this in your normal workflow, you’ll have to make sure that everyone on your team understands how to do so. If you don’t, you’ll end up spending a lot of time helping people figure out how to rewrite their commits with signed versions. Make sure you understand GPG and the benefits of signing things before adopting this as part of your standard workflow.
I'm presuming the Git engineers have modeled the Git workflows. They identified a problem (or problems), and they placed the "commit signing" security control to remediate it. I'd like to know what problems they identified and solved with "commit signing".
I think what has happened is folks are confusing/conflating Authentication with Authorization or maybe Code Integrity. Unfortunately, Authentication is not Authorization or Code Integrity despite the willingness to make it so.
What problem does git commit signing solve?
808
By signing your commits you can prove that the commit actually came from you. This is needed because it is pretty easy to add anyone as the author of a commit. This is not a security vulnerability by itself. But it could be used to hide the real author of malicious code.
You can sign commits locally using GPG, SSH, or S/MIME. Note: GitHub Desktop only supports commit signing if your Git client is configured to sign commits by default. Tips: To configure your Git client to sign commits by default for a local repository, in Git versions 2.0.
The git commit command will save all staged changes, along with a brief description from the user, in a “commit” to the local repository. Commits are at the heart of Git usage. You can think of a commit as a snapshot of your project, where a new version of that project is created in the current repository.
It means that when you commit code, the commit is signed with a key, the GPG key. This key contains information about you, like your name and e-mail address. When you submit your public key in GitHub, GitHub can verify that the signed commit was created by your account.
The problem that commit signing solves is the same problem that digitally signing a document solves: the problem of verifying its author.
Since only the author has their private key, only they can sign the commit as themselves.
If I trust an particular comitter and they have signed their commit, I can trust their code without necessarily hand-verifying every line.
Consider the case where someone forked your repository on github and then added a bunch of commits which introduced security vulnerabilities to your code. They made these commits with the tuple author name, author email, commit name, commit email set to one of the original authors.
Without commit signing, there is no way to verify that they are not the original author.
With commit signing, these forged commits cannot be signed because the forger does not have the author's private key.
107
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
