gpg --verify: Check a Signature in CI
gpg --verify confirms a signature was made by a known key over the exact data you have.
Verification is the gate that stops a tampered artifact from shipping. Give gpg the signature and the data, and it tells you whether the signature is good and whose key made it.
What it does
gpg --verify checks a signature. For a detached signature you pass both the .sig/.asc and the data file; for an inline or clearsigned message you pass just the signed file. It prints "Good signature" or "BAD signature" and the signer, and sets the exit code accordingly.
Common usage
# detached: signature first, then the data
gpg --verify file.tar.gz.asc file.tar.gz
# inline / clearsigned message
gpg --verify SHA256SUMS.asc
# machine-readable status for scripting
gpg --status-fd 1 --verify file.tar.gz.sig file.tar.gzOptions
| Flag | What it does |
|---|---|
| --verify | Verify a signature |
| --status-fd <n> | Emit machine-readable GOODSIG/BADSIG status lines |
| --keyring <file> | Verify against a specific keyring |
| --no-default-keyring | Ignore the default keyring |
| --trust-model always | Skip the "not certified" warning on otherwise good sigs |
In CI
gpg --verify returns exit 0 only for a good signature, so you can gate a job on it directly. A valid signature from an untrusted key still prints "WARNING: This key is not certified" but exits 0; do not treat that warning as failure. For strict checks, parse --status-fd output for VALIDSIG with the expected fingerprint.
Common errors in CI
"gpg: Can't check signature: No public key" means the signer key is not imported; import it first. "gpg: BAD signature" means the data changed after signing or you paired the wrong data and signature. "gpg: verify signatures failed: unexpected data" usually means you passed the data and signature arguments in the wrong order.