Code Security — The Importance of Securing Your Version Control

Why Everyone Should Be Using GPG Keys with Their Source Code

By Luke Oliff | Dec 19, 2018 | 8 min read

I’m going to attempt to share my experience (read: paranoia) for software security and how I make sure commits in my name were definitely me.

Dreaming up Nightmare Scenarios

1. You’re a maintainer for a well-used package that validates a token against publically accessible keys. As a result, you have access to both the key and the decoded user data. Steve steve@gmail.com is a key contributor but only you have permission to merge or tag releases.
2. You’re a business who’s software is in a private repository that is only modified by staff. Steve is a member of staff, but all members of staff can merge or tag releases.
3. A Git Horror Story

Steve helpfully creates a PR for a long-standing and frustrating issue to do with date formatting and daylight savings. All the CI tests passed. There are no conflicts. Great, what’s to worry about? Your cursory glance of the source code about to be merged into your package looks great! It fixes that issue you’ve been procrastinating about for months.

MERGE.

Two weeks later, two new related issues pop-up. What now? Oh. Somehow, an inconspicuous line has snuck in. It’s serializing the user object and the token and logging it to a strange syslog stream you’ve never seen before.

Git log shows the commits are from your buddy Steve.

$ git log
commit ee89a2d89f235863a8ae71ac27ee68deeb88d55e
Author: Steve G <steve@gmail.com>
Date:   Thu Dec 13 09:10:00 2018 +0000
    Code tidy up
commit a61a1f236e7fe55c99cba212f69be58e71e3cbb7
Author: Luke Oliff <luke@gmail.com>
Date:   Thu Dec 11 23:00:00 2018 +0000
    Recent legit changes

You see, anyone can spoof a commit.

git config --global user.email "steve@gmail.com"
git config --global user.name "Mr Steve"
git commit -m "Fixes issue 123"

How Does Git Help Secure Your Code?

Git uses SHA-1 to hash a snapshot of your repository. Once a file changes, the hash changes. This means that a file can’t change without Git’s knowledge, maintaining the integrity of the source code.

Git uses system information to assign an identity to commits. Unfortunately, it doesn’t verify identity — you can tell Git you’re whoever you want to be.

It Isn’t Enough

None of the standard “security” would prevent a bad actor that has access to the repository from spoofing you and committing malicious code. There are no guarantees that commits are by the person in the git log.

Signing Your Commits

With Git v1.7.9+, you can sign commits — not just tags. This verifies the identity for each commit made to the Git database.

Steps to sign commits with GPG on GitHub

1. Download the GPG command line tool for your OS.
2. Generate a key: gpg --full-generate-key
3. Select RSA and RSA (GitHub supported). Key size: 4096. Set an expiry.
4. List keys: gpg --list-secret-keys --keyid-format LONG
5. Tell Git: git config --global user.signingkey <YOUR_KEY_ID>
6. Sign all commits: git config --global commit.gpgsign true
7. Export: gpg --armor --export <YOUR_KEY_ID>
8. Add to GitHub at github.com/settings/keys

Ten More Best Practices for Code Security

1. Never use privileged, shared or system accounts for committing changes.
2. Never assume identity based on email.
3. Do not trust a PGP/GPG key by default.
4. Protect your private key WITH YOUR LIFE.
5. Keep expiry times short and use a strong password.
6. Enforce signing by all committers.
7. Always have a trusted single source-of-truth for your repository.
8. Configure and review access rights regularly.
9. Isolate environments — use git archive to deploy code only.
10. Use .gitignore to avoid committing sensitive files.

Conclusion

Spoofing commits is a threat to software integrity. Sign your commits.

---

Tags: Git, Software Security, Github, GPG