The gpg man page states "RETURN VALUE, The program returns 0 if everything was fine, 1 if at least a signature was bad, and other error codes for fatal errors.", as gpg is often used as a backend the return value is often used to determine whether a signature verified correctly.
For example, you have an automated system that verifies a file has been signed by a key on a keyring that contains the public keys that you trust to provide the correct file. You might use:
gpg --batch --no-default-keyring --keyring trustedpeople.gpg --verify file.sig file
This command should return success if the file is signed by a key on trustedpeople.gpg, failure if file.sig is invalid, or not a signature file. I dicovered that a file consisting of multiple 0xca bytes will cause gpg to always return success, I think this might be a bug that could potentially have security impact in the scenarios similar to the one described above.
$ perl -e 'print "\xca"x"64"' > input.sig
$ gpg --verify input.sig anyfile; echo $?
The 0xca file also works when encoded in base64 in clearsigned (armored?) messages.
I've added Werner Koch to cc, who hopefully will be kind enough to provide some input? :)
I've noticed a fix was committed for this issue to svn, so we can unrestrict this bug now.
Werner: in your opinion, does this bug warrant an update?
GnuPG project has released 184.108.40.206 to address this issue, moving into vulnerabilities.
Crypto herd: please provide updated ebuilds.
arches please test and mark stable, thanks
stable on ppc64
Stable on hppa
Stable on alpha + ia64.
ok, glsa vote i guess. I vote YES.
Yes too, GLSA draft is in and ready.
arm mips and s390 should remember to mark stable to benefit from GLSA