https://github.com/mocdaniel/signed-commits-case-study
A short discussion of different commit-signing methods and how they are interpreted by GitHub
https://github.com/mocdaniel/signed-commits-case-study
docs how-to
Last synced: 5 months ago
JSON representation
A short discussion of different commit-signing methods and how they are interpreted by GitHub
- Host: GitHub
- URL: https://github.com/mocdaniel/signed-commits-case-study
- Owner: mocdaniel
- Created: 2023-07-19T16:03:36.000Z (almost 3 years ago)
- Default Branch: main
- Last Pushed: 2023-07-19T16:25:13.000Z (almost 3 years ago)
- Last Synced: 2025-04-09T02:51:13.368Z (about 1 year ago)
- Topics: docs, how-to
- Homepage: https://dbodky.me
- Size: 7.81 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Signed Commits - a case study
Signing commits drastically hardens your repository against attempts to commit malicious code, e.g. via commit spoofing. Commit signing in addition to some features of GitHub, such as [Vigilant mode](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits), can help you make sure to only accept verified commits by contributors you know and trust.
This repository attempts to serve as a demo of the "look 'n feel" of commit signing on GitHub, and the different possibilities to do so.
We will look at three ways to sign commits - using `GPG` keys, `SSH` keys, and `gitsign` - and what the results look like on GitHub.
## Using GPG keys
### 1. Commit - signed by a valid user
The first commit is an authentic one:
- it was drafted by the **repository's owner** (`mocdaniel`) from his **verified email address** (`dbodky@gmail.com`)
- it has been signed by a GPG key which has been **linked** to the author's account.
You can have a look at the **commit history** of a repository at all times by navigating to the `Commits` tab in the top of the repo, or [following this link](https://github.com/mocdaniel/signed-commits-case-study/commits/main).
### 2. Commit - signed with a non-verified GPG key
The second commit is a bit weird:
- it seems to originate from `mocdaniel`
- **but** the GPG key is `unverified`?
Maybe the user just messed up his key management, or he forgot to **upload his public gpg signing key** for this key. Maybe it's a quite intricate attempt of getting malicious code in - in general it's better do decline commits like this or have a proper second look!
You can do so by cloning the repository and looking at the history via `git log --show-signature`, btw:
```console
git log --show-signature
commit 1bc84ab1f6b65e55e9dfec883fbe65c494d689d5 (HEAD -> main)
gpg: Signature made Wed 19 Jul 2023 06:07:01 PM CEST
gpg: using EDDSA key 5530A1A2EF240BCE0AE9185EF478C71B38B9AD9E
gpg: Good signature from "Daniel Bodky " [ultimate]
Author: Daniel Bodky
Date: Wed Jul 19 18:07:01 2023 +0200
Second commit
commit 60b9d6a151cd08a21f134bb941cb4dbfc9cf395a
gpg: Signature made Wed 19 Jul 2023 06:05:13 PM CEST
gpg: using EDDSA key 738DC9BC3F567CB282E5B29C9E12D1B1F1A84FA8
gpg: Good signature from "Daniel Bodky " [ultimate]
Author: Daniel Bodky
Date: Wed Jul 19 18:05:13 2023 +0200
First commit
```
### 3. Commit - Who's cloudnativeclutter?!
The third commit is *definitely* weird:
- it shows **cloudnativeclutter** (my blog's GitHub user) as author
- again, the commit is `unverified`, this time because I got **vigilant mode** configured for this account
Spoofing commits is as easy as changing the `user.email` and `author.email` field of your git config, thus changing the email address **GitHub** sees upon committing. Since GitHub is a **collaborative coding platform**, it will try to resolve this email address and display the author's information - totally fooling everyone who doesn't look twice!
## Using SSH keys
### 4. Commit - signed with a verified SSH key
The fourth commit is very similar to the first one:
- it comes from the repository's owner
- it is `verified`
The only difference is a tiny detail: Instead of a **GPG Key ID** we see a **SSH Key Fingerprint** when clicking on the `verified` badge now.
### 5. Commit - signed with an unverified SSH key
Let's go ahead and sign our fifth commit with a non-verified SSH key, similar to commit 2:
- the author is correct
- ...but the signature isn't
Once again, GitHub warns uns that it couldn't verify whether the stated author actually *is* the author, due to the signature not being verified. That's good!
### 6. Commit - We've been blessed by Octocat!
The sixth commit seems off again. Octocat has contributed to this humble guide?
- this time, it's worse - Octocat doesn't seem to use commit signatures!
- the commit seems authentic, and without a `(un)verified` badge, it's hard to tell who wrote this commit.
This is a perfect example of how easy it is to spoof arbitrary identities on GitHub for malicious purposes.
## Using `gitsign`
The third method I want to show is `gitsign`, a way to do keyless commit signing! If you don't feel like fiddling with GPG or SSH keys, this might be for you. More information about gitsign as a tool can be found on [the project's repository](https://github.com/sigstore/gitsign).
`gitsign` signs your commits using your very own **GitHub** or **OIDC** entity. All you need to do is to configure your local repository (or global settings). Once configured, upon (to be signed) commit, a browser window will opeb, and you will have to confirm your identity with the configured OIDC service provider - currently, GitHub, Microsoft, and Google are supported.
### 7. A valid signed commit using gitsign
What's that? The heading says it's supposed to be a **valid** commit signature, yet GitHub displays it as `unverified`? This has a reason - `gitsign` takes a different approach to signing commits than the previous methods by using **short-lived** certificates and a signature database called `Rekor` which persists signatures and can be queried in the future to validate existing signatures.
While this is not optimal for GitHub's UI, having a remote authority guaranteeing the authenticity of a signature can be helpful for checks in pipelines, scheduled checks, and audits, as the checking entity doesn't need to know whether a used SSH/GPG key is actually valid in the context of the identity used for the commit.
Nonetheless, the sigstore team is working together with GitHub to eventually be able to display a shiny `verified` badge on your commit histories, too!