gpg --verify behaves differently when multiple signatures present with --batch

[Daniel Kahn Gillmor]

when i have a set of OpenPGP signatures bundled together which have
different validities, it looks like gpg behaves differently depending on
if --batch is set or not.

In particular, an invalid signature seems to terminate the entire
--verify process (skipping later valid signatures) when --batch is set,
but it does not terminate the verification process otherwise.

Attached are two files: one is a simple shell script to demonstrate the
problem (with embedded data and signature material), and a fake key used
in the demonstrations.

When i run it, i get the following output (AB means the good sig from
the fake key occurs first, BA means the bad sig from my own key
(D21739E9) happens first:

> 0 dkg at pip:~/src/gmimetest/gmimetest$ ./demonstrate-flip
> Testing without --batch:
>  ==AB== 
> [GNUPG:] SIG_ID 8Dv9B4/7/rdjgFrLYlRGhj31b3o 2010-11-21 1290318596
> [GNUPG:] GOODSIG FAF286F977F50B3B fake user <fake at example.org>
> [GNUPG:] VALIDSIG FCD3E0AFA74EE527C61E0D34FAF286F977F50B3B 2010-11-21 1290318596 0 4 0 1 10 01 FCD3E0AFA74EE527C61E0D34FAF286F977F50B3B
> [GNUPG:] TRUST_UNDEFINED
> [GNUPG:] BADSIG CCD2ED94D21739E9 Daniel Kahn Gillmor <dkg at fifthhorseman.net>
>  ==BA== 
> [GNUPG:] BADSIG CCD2ED94D21739E9 Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> [GNUPG:] SIG_ID 8Dv9B4/7/rdjgFrLYlRGhj31b3o 2010-11-21 1290318596
> [GNUPG:] GOODSIG FAF286F977F50B3B fake user <fake at example.org>
> [GNUPG:] VALIDSIG FCD3E0AFA74EE527C61E0D34FAF286F977F50B3B 2010-11-21 1290318596 0 4 0 1 10 01 FCD3E0AFA74EE527C61E0D34FAF286F977F50B3B
> [GNUPG:] TRUST_UNDEFINED
> Testing with --batch:
>  ==AB== 
> [GNUPG:] SIG_ID 8Dv9B4/7/rdjgFrLYlRGhj31b3o 2010-11-21 1290318596
> [GNUPG:] GOODSIG FAF286F977F50B3B fake user <fake at example.org>
> [GNUPG:] VALIDSIG FCD3E0AFA74EE527C61E0D34FAF286F977F50B3B 2010-11-21 1290318596 0 4 0 1 10 01 FCD3E0AFA74EE527C61E0D34FAF286F977F50B3B
> [GNUPG:] TRUST_UNDEFINED
> [GNUPG:] BADSIG CCD2ED94D21739E9 Daniel Kahn Gillmor <dkg at fifthhorseman.net>
>  ==BA== 
> [GNUPG:] BADSIG CCD2ED94D21739E9 Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> 0 dkg at pip:~/src/gmimetest/gmimetest$ 


And if i use a test user that doesn't actually have a copy of D21739E9
in its keyring, then i get feedback from both signatures even in order
BA with --batch (i suppose because the keyring can't tell that the
signature for D21739E9 is bad).

I see no good reason for --batch to cause gpg to terminate on the  first
badsig it sees, and no documentation justifying this behavior, so it
seems like a bug to me.

I tested this with gpg 1.4.11 and 2.0.14 on i386 GNU/Linux systems
running the current debian testing (gpg itself from debian's
experimental archive)

Regards,

	--dkg
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: demonstrate-flip
URL: </pipermail/attachments/20101121/d16350d6/attachment-0001.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fakekey.gpg
URL: </pipermail/attachments/20101121/d16350d6/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20101121/d16350d6/attachment-0001.pgp>