Junio C Hamano venit, vidit, dixit 10.11.2010 01:19: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html