Skip to content

Enjoy Kaizen

Why Sign Git Commits?

From the Making of Dads’ Breakfast

When choosing to trust code written by another person, I endeavour to take a measured risk. Consider the attack on CoPay, carried out via the compromise of an overlooked-on-update dependency, otherwise unrelated to the virtual currency exchange software concern.

Scenario: What if that code-contributing person is victimized by a masquerading identity thief, and goes on unknowingly promulgating the originating repository, now including commits of malicious code?

Challenge: When all is found out, is the whole identity compromised?

Resolution (GPG): Notify the certifier of the compromised GPG fingerprint. The master private key holder has de-certification authority over the signature certified for signing commits, and may revoke certification of the maligned signing certification, rapidly upon providing their own advertisement of change of certifications. Upon receipt of such a fingerprint or similar identifying information, revoke the compromised signing key and exercise stable surety-of-identity from the master key to generate and certify anew, a signing key for origination of authentic commits to the code repository. The identity is not the signing key, and the originator can readily have an assured identity with which to signify the authenticity of corrective actions and sundry commits.

I hope my original works are useful mechanisms by which surety-of-origination acts to strengthen the whole, now that I am signing my commits.

I have my master private key stored offline in an encrypted USB, but keep a signing subkey-pair on my local machine for day-to-day use. I ensured that my signing subkey was present on the shell where my development work was taking place, and configured my git client to use my signing subkey.

When I could manually sign any commit by git commit -S, and have it work as expected, it was then time to have git challenge for signature on every commit, by setting the global option: git config --global commit.gpgsign true.

On commit, I answer the challenge with my GPG passphrase to apply my signature using my private signing subkey. Such signed commits are indicated as verified by both my-own installation of Gitea at and third-parties Github, et al.

My signing certificate expires two (2) years from the day I certified it, on 2021-03-16. If I go down, I’m taking all my certificates with me! 😀 That’s the graceful failure mode, and hopefully unnecessary for a very long time while I give it some more thought!

I welcome criticism, discussion and advice of the reader, that we may talk awhile.

I found the article Create GnuPG key with sub-keys to sign, encrypt, authenticate by Gerhard, via Tinned Software, helpful in getting started with GPG.

I found the article Using an offline GnuPG master key by Damien Goutte-Gattat helpful in learning to remove the secret from my master key, such that I now have an offline master key in encrypted, cold storage, while continuing to have the convenience of signing keys on my workstation.


1 Response

Leave a Reply

Your email address will not be published. Required fields are marked *