Verifying Git commits using GPG

Digital Signatures are used to sign texts, letters and other messages. Git is no exception, but why do we need it?

Why to sign Git commits

When we fill out documents, we sign to acknowledge that we have read the document and take responsibility for its contents.

In git, we need to make it clear that I wrote the code and everything in the commit was written by me. But why?

Git solves a lot of development problems, but there are just as many loopholes for spoofing.

Git commits are based on trust, and most commit developers use simple credentials to identify the commit author, such as user.name and user.email.

Unfortunately, this data can easily be spoofed by someone else knowing your name and email. When submitted to a remote repository, the commit will show something other than your name and a link to your profile.

Keep in mind that the author on the commit is just an indication of the author, not proof that this person did the work.

Sounds strange, doesn't it? We use our repository account to submit, not just email. Unlike change push, commits don't take into account who the author or committer is, they use a configuration setting.

How do you prove you're a committer and not a liar?

Signing your commit solves this problem. Now no one can impersonate you and give away someone else's code as yours. All you need to do is have the encryption key and use it when you commit.

In addition you get a nice green Verified sign next to your commit.

GnuPG is an excellent tool for encrypting and signing your data. GPG creates a key pair: private and public keys. You'll need the public one to sign it. We will export this public key into our GitHub and GitLab accounts later.

The more you value the security of your application, the more you have to pay attention to your code and its authors.

You can set up your projects so that pushing into protected branches requires all commits to be signed.

View the list of existing keys on the system:

gpg --list-secret-keys --keyid-format LONG

B38EC0C87C413474 - fingerprint of the private key.

If you do not have a key, you can generate it with the command:

gpg --full-generate-key

Read the GPG article to learn more about the creation and use cases.

To upload a public key to GitHub and GitLab, you'll have to export it.

gpg --armor --export B38EC0C87C413474

The result is that we now have the contents of the public key, which we copy and use for our account.

-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBGObaKUBEACjfWN6hEiwSBXbHX1VCnlG8oO08gTToAVcRlfEjIyF5wixboUw
Fhp6jTsLyKlju7J9ucvIxsWC1a7nuNgC8cLM5mpqOkAIUMnmmxX3EipP8cPDDZLk
X9lPqfkSgQXJmUGV8xrh1LhOAOwxEmJVkB8Se44Gg74KoXOsEw2lx/KnoOvmBAuo
...
-----END PGP PUBLIC KEY BLOCK-----

Note that you copy the entire key, with the BEGIN PGP PUBLIC KEY BLOCK and the END PGP PUBLIC KEY BLOCK

Setting up Git to sign commits

You can set up a Git signature with a pair of keys from gpg signing:

git config --global user.signingkey B38EC0C87C413474

You can now sign commits with a key if you specified the -S flag when you created them.

git commit -S

You can also tell Git to automatically sign all your commits:

git config --global commit.gpgSign true

Adding the GPG key to GitHub

Add GPG key (public key) to the SSH and GPG settings page, which will link it to your account.

Adding the GPG key to GitLab

Add GPG key (public key) to the GPG settings page, which will link it to your account.

Conclusion

Signing tags and commits is a wonderful idea, without a doubt, but if you decide to incorporate it into your daily workflow, you need make sure that everyone on your team is familiar with the process.

Have you signed your commits yet?