Yes, if upstream signs its release tags. The verify-tag command checks the signature on a tag, and you run it before merging. It proves a key signed that tag. It does not prove the key belongs to the right person unless you already trust it, and it says nothing about whether the code is safe.
What the command does
The Git documentation describes verify-tag as validating the GPG signature created when a tag is made with the signing option. You pass it a tag name and it reports whether the signature is good or bad, using keys in your local keyring.
git fetch upstream --tags
git verify-tag v2.4.0
A good result means the tag object was signed by a key your keyring knows, and the tag has not been altered since. A bad result, or no signature at all, means you should stop and look.
What it does not prove
A signature has three weak points worth naming.
- Key trust. If you imported the key from the same place you got the tag, a swap could fool you. Get the maintainer's key fingerprint through a second channel, such as the project website or a signed release announcement, and compare.
- Signer intent. A valid signature shows a key signed, not that the signer reviewed every commit. A maintainer account takeover with a stolen key still produces valid signatures.
- Coverage. Many projects do not sign tags at all. An unsigned tag is not a sign of attack, but it means this check is unavailable and you need other checks.
A routine that fits in a sync
| Step | Check | If it fails |
|---|---|---|
| 1 | Does upstream publish signing keys and sign tags? | Note it, rely on step 4 |
| 2 | Is the key fingerprint confirmed from a second source? | Do not trust the result yet |
| 3 | Run verify-tag on the release tag | Stop, ask upstream |
| 4 | Read the diff between your base and the new tag | Escalate anything unexplained |
| 5 | Rebuild and rescan | Block the sync if new findings appear |
Step 4 does the heavy lifting for every project, signed or not. See reviewing the upstream diff before merging it into your fork.
Pin what you verified
After a good check, record the tag name and the commit it points at in your fork notes. Tags can be moved, so the commit ID is the stable fact. The describe command can label your base relative to the nearest tag, which makes the note easy to write.
If you later find the tag points somewhere else, treat that as an incident, not a typo. A moved release tag is a reason to pause syncs until upstream explains.
Pair it with a second source
Where the project also publishes build attestations or checksums, compare them to what you built or fetched. Two independent signals are worth more than one strong one. For the wider question of whether valid provenance means safe, see valid provenance does not mean safe.
Where Safeguard fits
Signature checks cover who published, not what the code contains. Safeguard's dependency scanning and policies can gate a sync on what the resulting build includes. Try a free scan at gold.safeguard.sh/scan.
Quick check
Does a good signature mean the release is safe?
No. It shows a trusted key signed the tag. The code can still contain a flaw or a malicious change if the signer was compromised or careless.
What if upstream does not sign tags?
Skip that check, and rely on diff review, a rebuild and a rescan. Ask the project whether it plans to sign releases.
Sources
Last reviewed: 19 October 2026.
