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. Reproduce: $ 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 1.4.2.1 to address this issue, moving into vulnerabilities. Crypto herd: please provide updated ebuilds.
Done.
arches please test and mark stable, thanks
amd64 stable
ppc stable
stable on ppc64
x86 done
SPARC'd
Stable on hppa
Stable on alpha + ia64.
ok, glsa vote i guess. I vote YES.
Yes too, GLSA draft is in and ready.
GLSA 200602-10 arm mips and s390 should remember to mark stable to benefit from GLSA
mips stable.