Signed Commit
Introduction
Signed commits are a Git feature that lets contributors cryptographically verify their identity when making a commit, proving that a commit genuinely came from who it claims to come from.
The Problem They Solve
Git allows anyone to set any name and email address in their local configuration. Without signing, nothing stops a bad actor from impersonating another developer by simply setting user.name and user.email to someone else's values. Signed commits close this gap.
How They Work
A contributor generates a cryptographic key pair — most commonly using GPG (GNU Privacy Guard), though SSH keys and S/MIME certificates are also supported. The private key stays secret on the contributor's machine; the public key is uploaded to their account on platforms like GitHub or GitLab. When a commit is made with signing enabled, Git uses the private key to generate a cryptographic signature and attaches it to the commit object. Anyone with the public key can then verify that signature, confirming:
- Authenticity — the commit was made by whoever owns that private key
- Integrity — the commit contents have not been tampered with since it was signed
What It Looks Like in Practice
Platforms like GitHub display a "Verified" badge next to signed commits. Unsigned or unverifiable commits show as "Unverified." Repositories can also enforce a branch protection rule requiring all commits to be signed before they can be merged, ensuring a full chain of verified authorship on critical branches. Common Use Cases
Open source projects that accept contributions from strangers and need to trust the commit history
Security-sensitive codebases where auditability of who changed what is critical
Regulated environments (finance, healthcare, government) with compliance requirements around code provenance
Supply chain security — preventing compromised or spoofed commits from introducing malicious code
Basic Setup (GPG)
bash# Generate a GPG key gpg --full-generate-key # Tell Git which key to use git config --global user.signingkey <KEY_ID> # Sign commits automatically git config --global commit.gpgsign true # Or sign a single commit manually git commit -S -m "your message" # Verify a commit's signature git verify-commit <commit-hash>
Key Concepts Summary
| Term | Meaning |
|---|---|
| GPG/PGP key | The most common key format used for signing commits |
| Verified badge | Platform confirmation that the signature checks out |
| Vigilant mode | A GitHub setting that marks all unsigned commits as unverified |
| Keyserver | A public directory where you can publish your public key |
Lingoport Localyzer
gpg and git
Both GPG and Git are part of the Docker image provided by Lingoport. See:
tomcatuser@42216e9ba140:~$ git --version git version 2.34.1 tomcatuser@42216e9ba140:~$ gpg --version gpg (GnuPG) 2.2.27
Git Data Sources
Data Sources are associated with a Git account, with a username and an email. For signed commits, this account must be verified. For instance, if the email is not verified, signed commits cannot be verified.
For signed commits, a Localyzer project must have a GPG configuration using that Git Data Source username and email.
git config --get user.name && git config --get user.email John Doe jdoe@acme.com
Create GPG keys and associate it with GitHub
From the container, create the GPG using the Data Source username and email as indicated. Do not use passphrase (empty), as this would be required as an input when running git commands from Localyzer.
For example, for GitHub: