This error occurs when Git tries to verify a GPG-signed commit or tag, but the signer's public key isn't in your local GPG keyring. Import the missing public key from a keyserver or directly from the signer to verify the signature.
When developers sign Git commits or tags using GPG (GNU Privacy Guard), they create a cryptographic signature using their private key. To verify these signatures, you need the corresponding public key in your GPG keyring. The "gpg: Can't check signature: No public key" error appears when you run commands like `git log --show-signature`, `git verify-commit`, or `git verify-tag`, and GPG cannot find the public key needed to verify the signature. The error message typically includes an RSA key ID (e.g., `RSA key ID A9C5DF4D22E99998D9875A5110C01C5A2F6059E7`) which identifies the missing key. This is not a critical error that prevents Git operations - unsigned commits and tags work normally. However, you cannot verify the authenticity of signed commits until you import the signer's public key. This verification is particularly important in security-conscious workflows where you need to confirm that commits came from trusted developers.
First, find the key ID that GPG is looking for. Run the verification command and note the key ID:
git log --show-signature -1The output will show something like:
gpg: Signature made Mon 01 Jan 2024 12:00:00 PM UTC
gpg: using RSA key A9C5DF4D22E99998D9875A5110C01C5A2F6059E7
gpg: Can't check signature: No public keyNote the key ID (the long hexadecimal string after "using RSA key").
Try to fetch the public key from a keyserver using the key ID:
gpg --keyserver hkps://keys.openpgp.org --recv-keys <KEY_ID>For example:
gpg --keyserver hkps://keys.openpgp.org --recv-keys A9C5DF4D22E99998D9875A5110C01C5A2F6059E7If the default keyserver doesn't have the key, try alternative keyservers:
# MIT keyserver
gpg --keyserver hkps://pgp.mit.edu --recv-keys <KEY_ID>
# Ubuntu keyserver
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys <KEY_ID>If the commits were made through GitHub's web interface (merges, edits via UI), you need GitHub's web-flow key:
curl https://github.com/web-flow.gpg | gpg --importThis imports the key GitHub uses to sign commits made through their web interface. You can verify it was imported:
gpg --list-keys [email protected]For commits signed by other GitHub users, their public keys may be available at:
curl https://github.com/<username>.gpg | gpg --importIf you have the public key as a file (often provided in project documentation or by the developer directly):
gpg --import publickey.ascOr import from a URL where the key is hosted:
curl https://example.com/developer-key.asc | gpg --importSome projects include signing keys in their repository:
gpg --import KEYS
# or
gpg --import signing-key.pubAfter importing the public key, verify the signature again:
# For commits
git verify-commit <commit-hash>
# or
git log --show-signature -1
# For tags
git verify-tag <tag-name>
# or
git tag -v <tag-name>A successful verification shows:
gpg: Signature made Mon 01 Jan 2024 12:00:00 PM UTC
gpg: using RSA key A9C5DF4D22E99998D9875A5110C01C5A2F6059E7
gpg: Good signature from "Developer Name <[email protected]>" [unknown]After importing a key, GPG may show "[unknown]" trust level. If you trust the key's authenticity, you can set the trust level:
gpg --edit-key <KEY_ID>At the gpg> prompt, type:
gpg> trustSelect a trust level:
- 1 = I don't know or won't say
- 2 = I do NOT trust
- 3 = I trust marginally
- 4 = I trust fully
- 5 = I trust ultimately (use for your own keys only)
Then save and exit:
gpg> saveNote: Setting trust levels is part of the GPG web of trust model and should be done carefully. Only set high trust for keys you've verified through out-of-band means.
### Automating Key Imports in CI/CD
For CI/CD pipelines that need to verify signatures, pre-import the required keys:
# Import multiple keys in a script
gpg --keyserver hkps://keys.openpgp.org --recv-keys KEY1 KEY2 KEY3
# Or import from a team keyring file stored in the repo
gpg --import .gpg-keys/team-keys.asc### Verifying All Commits in a Range
To check signatures for multiple commits:
# Show signatures for last 10 commits
git log --show-signature -10
# Verify signatures for commits in a branch
git log --show-signature main..feature-branch### Using git merge --verify-signatures
Git can verify signatures during merges:
git merge --verify-signatures feature-branchThis will refuse to merge if any commits have invalid or missing signatures.
### GPG Key Distribution Best Practices
If you're signing commits and want others to verify them:
1. Upload to keyservers: gpg --keyserver hkps://keys.openpgp.org --send-keys <YOUR_KEY_ID>
2. Add to GitHub: Settings > SSH and GPG keys > New GPG key
3. Include in project: Add your public key to a KEYS file in the repository
4. Document: Include verification instructions in your README
### Handling Expired or Revoked Keys
If verification shows an expired or revoked key:
gpg: Signature made Mon 01 Jan 2024
gpg: Note: This key has expired!The signature may still be valid if it was made before the key expired. To see key details:
gpg --list-keys --keyid-format LONG <KEY_ID>### Corporate Environments
In enterprise settings, you may need to:
1. Configure a corporate keyserver: Add to ~/.gnupg/gpg.conf:
keyserver hkps://keys.internal.company.com2. Import corporate root keys that sign developer keys
3. Use LDAP or Active Directory integration for key distribution
warning: BOM detected in file, this may cause issues
UTF-8 Byte Order Mark (BOM) detected in file
fatal: Server does not support --shallow-exclude
Server does not support --shallow-exclude
warning: filtering out blobs larger than limit
Git partial clone filtering large blobs warning
fatal: Server does not support --shallow-since
Server does not support --shallow-since in Git
kex_exchange_identification: Connection closed by remote host
Connection closed by remote host when connecting to Git server