Re: [PATCH 1/5] t/t7004-tag: test handling of rfc1991 signatures

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Nov 10, 2010, 08:23 UTC
Message-ID: <4CDA569F.5090901@drmicha.warpmail.net>
In-Reply-To: <7vhbfqjaho.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 10.11.2010 01:19:

Show 7 quoted lines

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> The --rfc1991 option matters for the creation of signatures only, not
>> for the verification (and neither for display/listing with git, of course).
> 
> Doesn't the above statement assume a bit too much about how the current
> version of gpg behaves, I have to wonder?

[Note: I'm sick and may sound even more grumpy than usual...]

* This test (and the patches) is about making signed tags work for
people with rfc1991 in their options. This is why I put rfc1991 in gpg's
option file.

Note that git always produced rfc1991 sigs for those users, and always failed to verify/list them properly, no matter what gpg option is active during the verify/list phase.

* If you /also/ want to test that users without --rfc1991 can very those
rfc1991 sigs one would need an additional test after the "rm...". I'm
telling you that --rfc1991 is completely irrelevant for what gpg
accepts, and thus the additional test is completely superfluous. gpg is
lenient about what it accepts (within existing rfc's) and strict about
what it produces (according to what you tell it to do), just like it
should. This is by design and intentional, not version dependent or by
chance. (Even requesting strict openpgp mode does not change this.)

So, the rm needs to stay where it is.

I could repeat the three tests again after the rm, albeit in different order so that the first one has no chance of rewriting the rfc1991 sig into an openpgp sig. I have no objection against that, it does no good and no harm.

Michael