gpg: BAD signature from "Release Bot <release@example.com>" [ultimate]

The user ID in quotes and the trust level in brackets (`[ultimate]`, `[full]`, `[unknown]`) come from your keyring.

What it means

gpg had the signer's public key and checked the signature, and the check failed: the data is not what the key holder signed. Unlike "No public key", this is a definitive negative result — the file or object was changed after signing, or the signature belongs to different data. Treat the content as untrusted. The bracketed word is your trust level for the key, not part of the verdict.

Why it happens

• The data was changed after signing

  common

  A tampered download, an edited checksum file, or a commit object rewritten without re-signing. This is exactly what the signature exists to reveal.

• Line endings or encoding were converted

  common

  Git's `autocrlf`, FTP in ASCII mode, or an editor that adds a final newline changes the bytes of text files, and a detached signature over the original bytes no longer matches.

• Signature and file do not belong together

  occasional

  A `.asc` from one release verified against the file of another, or a signature for the tarball checked against the checksum file.

How to fix it

1. 1.

   Get both files again and re-verify

   If the result stays BAD with files obtained over a trustworthy channel, do not use the content and notify the publisher.

   # Fetch both files again over a verified channel and compare
   sha256sum release.tar.sha256
   curl -sSLO https://example.com/downloads/release.tar.sha256
   curl -sSLO https://example.com/downloads/release.tar.sha256.asc
   gpg --verify release.tar.sha256.asc release.tar.sha256

2. 2.

   Protect signed text files from conversion

   Mark signature and checksum files as binary in `.gitattributes` so line-ending conversion never touches them.

   # .gitattributes: never convert line endings of signed files
   *.asc  -text
   *.sig  -text
   SHA256SUMS -text

← Browse the full signature error database