29. 10. 2024 Alessandro Taufer Development, DevOps

Is Signing git Commits Really Useful?

Securing your codebase is a fundamental step in guaranteeing the integrity of your software: if the access to your git commits is compromised, so is your whole supply chain. That’s the reason why almost every git hosting service has implemented a strong authentication system to protect their users from unauthorized access.

The question naturally arises then, why do I have to sign my commits if I already have to authenticate using an ssh key to push the code?

Let’s try to answer this.

Integrity

The main problem lies in the fact that “git” is different than “git provider”, so even if we want to push something into the codebase and we need to authenticate that, the git history will not retain this information. Consequently, we have to trust the git provider not to tamper with it, otherwise we wouldn’t have any meaningful way to distinguish which part of the code was written by a legitimate author and which part was injected.

But let’s be real here. By design git is a distributed versioning system, so every user who cloned the repository before any tampering took place would notice at the next git pull that the history had been rewritten.

In addition, GitHub is a very trusted git provider used by thousands of large scale companies, so it’s safe to assume that the probability of it being compromised (or even worse, of it maliciously injecting code in your codebase) is close to zero.

It’s true that signing commits would reduce this possibility to zero, but it’s an unrealistic scenario for most of us.

Beware though, if you’re using a self-hosted git provider, a mirror, or any kind of caching system (e.g., local git repositories that your CI updates at every run via a git pull) you’re not relying on the trustworthy GitHub security infrastructure, and consequently the probability of it being compromised increases significantly.

Identity Spoofing

The real deal in fact is the risk of identity theft. Even if GitHub ensures that the person pushing the code to the repository is a trusted contributor, that doesn’t mean that they didn’t name somebody else as the author of the commit.

A very fun example of this is the git-blame-someone-else tool.

You don’t think Linus Torvalds really contributed this, do you?

So that’s the reason why we should sign commits, to avoid me showing up as the person who injected the malicious code into the company repository?

Well, yes. But actually no. It just proves that the code was not signed with the same key as the one you usually use. Which, of course, is a big red flag indicating that the commit is probably spoofed. But it will never prove that you simply didn’t sign the commit (or used a different signature).

That’s why, on its own, signing commits does not provide real additional security.

Optimal Use of Signed Commits

However, that changes if your company implements a good and effective keychain trust policy:

Assume for example that your company implements a functionality that makes the repository accept only those commits that have a trusted signature (no, it’s not done by GitHub by default), which would avoid any identity spoofing as long as no private key is leaked.

On top of that, it could enforce a rule that every key must be signed with the company’s “root” signature (which of course has to be kept very safe) that would allow anyone (including the CI) to easily check the integrity of the git repository by trusting the public key and verifying the signature of the entire commit chain.

Like icing on the cake, custom logic can be added to give fine grained permissions to each user, for instance commits signed by person A will be accepted as long as they don’t alter the content of the file X, meanwhile commits signed by person B can only edit the file X.

It can be particularly useful in specific scenarios, like when you’re using a GitOps continuous deployment approach, where each change in the infrastructure should be applied automatically through a git commit.

Conclusion

We saw that the need to use signed commits might vary depending on the company infrastructure, and that’s why there’s a heated debate between those who use them and those who don’t.

I hope this article helped you with some new ideas to reflect on. Feel free to contact me, I’d love to know what you think about this.

Still looking for something new? Read one of my previous articles

These Solutions are Engineered by Humans

Did you find this article interesting? Does it match your skill set? Programming is at the heart of how we develop customized solutions. In fact, we’re currently hiring for roles just like this and others here at Würth Phoenix.