Commit Signing Keys
How to sign commits with a GPG or SSH key and have CollabOps verify them.
CollabOps verifies the signature attached to a commit and shows whether you really authored it. When verification succeeds, a Verified badge appears in commit lists and change requests.
Git does not check user.email. Anyone can put someone else's address in a commit. A signature covers the entire commit content, so changing the committer breaks it.
A commit signing key is a separate resource from an authentication SSH key. A key you registered for access does not automatically gain signing trust — register it as a signing key even if it is the same key material.
Step 1. Generate a signing key
Both SSH and GPG are supported. You only need one of them.
Signing with an SSH key
Generate a key dedicated to signing.
ssh-keygen -t ed25519 -C 'signing'Print the public key. You will paste this value into the registration form.
cat ~/.ssh/id_ed25519.pubSigning with a GPG key
Generate a key.
gpg --full-generate-key --expertFind the fingerprint.
gpg --list-secret-keys --keyid-format=longExport the public key in armored form. Enter both the fingerprint and the public key in the registration form.
gpg --armor --export <FINGERPRINT>Step 2. Register the key with CollabOps
Open the commit signing key page. https://collabops.ai/<workspace>/settings/account/signing/new
Fill in the following and save.
| Field | Value |
|---|---|
| Key format | SSH or GPG |
| Title | A name you will recognize later (e.g. MacBook Pro (signing)) |
| Public key | The value you copied in Step 1 |
| Fingerprint | GPG only. For SSH the server computes it from the public key |
x509 (S/MIME) signatures are not supported yet.
Step 3. Configure Git to sign
If you registered an SSH key
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519
git config --global commit.gpgsign trueIf you registered a GPG key
git config --global user.signingkey <FINGERPRINT>
git config --global commit.gpgsign trueThe committer email on the commit must match an email registered on your CollabOps account. Check it with:
git config user.emailIf a repository overrides user.email, or a noreply address from another service is left over, the signature can be valid and the commit will still show as Unverified.
Step 4. Verify the signature
Once configured, commit as usual. To sign a single commit, add -S.
git commit -S -m "feat: something"Check locally that a signature was attached.
git log --show-signature -1After pushing, look for the Verified badge in the CollabOps commit list.
A successful git log --show-signature locally does not mean CollabOps will verify it. Git does not know who owns the key. Only the server decides whether the key is registered and the email matches.
Reading the badge
Only two badges are shown: Verified and Unverified. Nothing is shown for unsigned commits or for commits we could not check. Hover the badge to see the reason.
| Badge | Reason | Meaning |
|---|---|---|
| Verified | Signed with a registered key and the committer email matches the key owner | All good |
| Unverified | The signing key is not registered | Not registered, or signed with a different key |
| Unverified | The committer email differs from the key owner's email | Check git config user.email |
| Unverified | The signature could not be validated | Broken signature or tampered commit |
| Unverified | Signed after the key was revoked | Signed post-revocation |
| Unverified | Signed after the key expired | Signed post-expiry |
| No badge | The commit is not signed | Normal (unsigned) |
| No badge | The signature cannot be checked right now | Temporary lookup failure — check again shortly |
Putting a grey badge on every unsigned commit would bury the verified ones, so unsigned commits get no badge.
Revoking vs. deleting a key
The key list offers both Revoke and Delete, and their effect on past commits is opposite.
| Revoke | Delete | |
|---|---|---|
| Meaning | I will stop using this key | This key is not mine |
| Future signatures | Not verified | Not verified |
| Past commit badges | Stay verified | Become unverified |
| When to use | Key rotation, lost device | Undoing a key registered by mistake |
Commits signed before revocation were signed with a key that was valid at the time, so they stay verified. Deleting removes the basis for trust itself, so badges on past commits signed with that key change too.
If you simply want to stop using a key, use Revoke. Delete also turns past commit badges to unverified.
Requiring signed commits
Add the require_signed_commits rule to a workspace ruleset and the branch will only accept signed, verified commits.
| Action | Result |
|---|---|
| push | Rejected if any commit is not verified |
| Merge | Blocked if the change request contains an unverified commit (squash included) |
| Rebase merge | Removed from the available methods |
| Merge commit / squash merge | Available |
Rebase rewrites the original commits into new objects that carry no signature from their author. Having the platform sign them instead would make changes the author never signed appear verified, so the method is removed entirely. Merge commit and squash only create one new commit without rewriting the originals, so they remain available.
If a verdict cannot be obtained, the rule blocks. Letting through what we could not check would defeat the rule.
Commits signed by the platform
Commits the server creates — web edits, merges, reverts, repository initialization — are signed with a CollabOps key. Their signer is shown as the platform rather than a person, and it does not stand in for a person's signature.
Troubleshooting
The committer email differs from the key owner's email
This is the most common failure. Verification checks three things: that the signature is cryptographically valid, that the key is registered and still valid, and that the commit's committer email is a verified email of the key owner. The third one is what usually breaks.
git config user.email # current repository
git config --global user.email # global settingSet it to an email registered on your CollabOps account and commit again. Badges on commits you already pushed will not change.
The signing key is not registered
Git may be signing with a different key than the one you registered. Check which key is actually used.
git config user.signingkeyI registered my access SSH key but signatures are not verified
A commit signing key is a separate resource from an authentication SSH key. Register it on the commit signing key page. Granting signing trust to an access key automatically would make that key a basis for trust without your intent and would blur the scope of a later revocation.
The terminal hangs when signing with GPG
GPG cannot find a way to prompt for the passphrase. Add the following.
export GPG_TTY=$(tty)Add it to your shell profile (~/.zshrc or ~/.bashrc) to apply it every time.
The commit is signed but no badge appears
Signature verdicts are fetched separately from the commit list, so the list renders first and badges follow. Reopen the page shortly after; if it still does not appear, hover the badge area to read the reason.