gpg --verify file.tar.xz.sig file.tar.xz

GPG Command Builder

Most GPG usage is four tasks with fiddly flags. Pick one and get the command, plus the step people skip that makes it actually work.

Leave empty to assume <file>.sig or .asc

"Good signature" plus a warning is normal

Verifying a download almost always prints WARNING: This key is not certified with a trusted signature, and almost everyone reads that as a failure. It is not. It means you have not personally vouched for the key in your own web of trust, which for a distribution signing key you fetched from the project website is entirely expected. The line that matters is Good signature. BAD signature means stop. The genuine weak point is how you obtained the key in the first place: a key pulled from the same page as a tampered file proves nothing.

Build GPG commands for verifying and signing

This GPG command builder covers the four things most people need GnuPG for: verifying that a downloaded file was signed by the project that published it, generating a key with an expiry and a revocation certificate, signing files and git commits, and encrypting either to a recipient public key or with a shared passphrase. It includes the surrounding steps that are easy to miss, such as importing the signing key first and setting GPG_TTY so commit signing works.

GPG FAQ

Why does verification fail with "no public key"?

You do not have the signing key, so there is nothing to check against. Import it first, ideally from the project website over HTTPS rather than a keyserver, since keyservers accept uploads from anyone and a matching name proves nothing.

What is the difference between .sig and .asc?

Both are signatures; .sig is binary and .asc is the same thing ASCII armoured so it survives email and web pages. Use --armor to produce .asc. Verification is identical either way.

Do I really need a revocation certificate?

Yes, and you need it before anything goes wrong. If your private key is lost or stolen there is no other way to tell the world the key is no longer valid; it simply stays on keyservers looking legitimate. Generate it at key creation and store it separately from the key.

Should I use GPG for encrypted messaging?

Generally no. GPG has no forward secrecy, the tooling is unforgiving, and key management defeats most people. It remains excellent for verifying software releases and signing commits, which is where the ecosystem actually depends on it.