gpg --verify gives a bad signature warning

gpg --verify is giving me a bad signatures more often than I'd expect. Just this week, two libraries have given me "BAD signature" warnings - Libsodium and chruby. I followed all the instructions on the chruby README and yet still I get a bad signature warning.

Are there some things I should check about my installation? Any help is much appreciated.

$ gpg --version
gpg (GnuPG/MacGPG2) 2.0.17
libgcrypt 1.4.6

Mac OSX 10.6.6

$ gpg --verify libsodium-0.2.tar.gz.sig
gpg: Signature made Tue 29 Jan 05:47:53 2013 GMT using DSA key ID 1CDEA439
gpg: BAD signature from "Jedi/Sector One <j@pureftpd.org>"

The chruby problem was fixed by using a different download method, the verification failed with a cURL download but using the Github website's links the file I downloaded worked. Tried the same with libsodium and it still fails, so maybe it's just libsodium's file?

Iain

Posted 2013-02-21T10:55:59.353

Reputation: 232

What if that persists when getting both files with wget and curl? E.g. with [Syslinux 6.03](https://www.kernel.org/pub/linux/utils/boot/syslinux/] while on Arch linux. gpg (GnuPG) 2.1.10 with libgcrypt 1.6.4, curl 7.46.0 and GNU Wget 1.16.3 I'll post on the Syslinux ml and will report to you eventualy .

– tuk0z – 2015-12-22T16:49:06.210

In that case the original signature is made against the .tar (unarchived) file so I oughta verify in on the gunziped tarball. OK. – tuk0z – 2015-12-22T17:16:54.727

1Please add the exact warning you're getting. – Jens Erat – 2013-02-21T11:28:42.667

@JensErat done. – Iain – 2013-02-21T11:32:25.327

Fetching both files using wget and then verifying the signature worked fine for me. I'm using the exactly same version of gpg. Try again using wget: wget http://download.dnscrypt.org/libsodium/releases/libsodium-0.2.tar.gz; wget http://download.dnscrypt.org/libsodium/releases/libsodium-0.2.tar.gz.sig; gpg --verify libsodium-0.2.tar.gz.sig. md5 hashes of these files: 621890d23a09049b6f54a720e082b642 for the tarball and 496c2f7d883b342b324b6d7da0e27681 for the signature. – Jens Erat – 2013-02-21T11:41:09.437

@JensErat I had to install wget, and once I did, it worked. Verifying files downloaded via Safari, Chrome and cURL gives the warning - very strange! Thanks for the help, it's much appreciated. If you'd like to post your comment as an answer I'll accept it. – Iain – 2013-02-21T12:20:05.740

Somehow the other clients seem to have fiddled somehow with the files, probably the tarball. You could try to use diff to trace that if you're interested. How did you invoke curl? – Jens Erat – 2013-02-21T12:28:03.673

@JensErat I ran curl -O http://download.dnscrypt.org/libsodium/releases/libsodium-0.2.tar.gz; curl -O http://download.dnscrypt.org/libsodium/releases/libsodium-0.2.tar.gz.sig; gpg --verify libsodium-0.2.tar.gz.sig; just now and it worked, so now I'm wondering if anything has changed now that it's worked with wget, but it shouldn't have. I've had enough of this to be honest! Just happy I've got it to work - I'll quit while I'm ahead :) – Iain – 2013-02-21T12:35:32.690

1"Probably your HTTP client somehow fiddled with the files" Yep, that happened to me; I used rsync and GPG verification succeeded. – Geremia – 2017-01-21T03:21:41.940

I haven't ever seen HTTP clients fiddling with files (other than translating Unix to Windows text line endings). Perhaps a compromised server? Re-check, please. And it would be interesting to compare the tampered file with the pristine one to find out what happened, please offer help to upstream in this. – vonbrand – 2013-02-21T13:31:48.243

1Translating line endings is enough fiddling for breaking checksums. That why I asked for diffing it in a comment above. Opening the signature file with some text editor could (but probably shouldn't) have the same effect. – Jens Erat – 2013-02-21T13:50:27.137

gpg --verify gives a bad signature warning

Answers