Bugzilla Bug 122721

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.