Re: [PATCH] tag,verify-tag: do not trip over rfc1991 signatures

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stephan Hugel venit, vidit, dixit 05.10.2010 22:51:
> On 5 October 2010 21:42, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote:
>> Junio C Hamano venit, vidit, dixit 05.10.2010 22:28:
>>> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>>>
>>>> Currently, git expects "-----BEGIN PGP SIGNATURE-----" at the beginning of a
>>>> signature. But gpg uses "MESSAGE" instead of "SIGNATURE" when used with
>>>> the "rfc1991" option. This leads to git's faling to verify it's own
>>>> signed tags.
>>>>
>>>> Be more lenient and take "-----BEGIN PGP " as the indicator.
>>>
>>> Thanks, but it bothers me that the patch is a bit inconsistently lenient.
>>>
>>> How many variants of PGP implementations are there?  For example, I'd ask
>>> these without doing my own research because I am lazy:
>>>
>>>  1. Does everybody place five dashes at the beginning (IOW, is there an
>>>     odd variant that puts four or six)?
>>>
>>>  2. Does everybody follow the dashes immediately with "BEGIN" (IOW, is
>>>     there an odd variant that puts a SP between them)?
>>>
>>>  3. Does everybody spell "BEGIN PGP " the same way, in all uppercase?
>>>
>>>  4. Does everybody place five dashes at the end (IOW, is there an odd
>>>     variant that puts four or six)?
>>>
>>>  5. Does everybody follow the "BEGIN PGP SOMETHING" immediately with
>>>     dashes without SP?
>>>
>>> Your patch seem to answer <yes, yes, yes, no, no> to the above question.
>>
>> On 4,5, my patch only implies that I (suggest we) don't care.
>>
>>> I'd find it saner if the patched code at least checked that the line ends
>>> with 5 dashes.
>>
>> Alternatively, we can just say we support gnupg/openpg but not pgp 2.0,
>> and running gpg with pgp 2.0 options is discouraged even by gpg's man page.
>>
>> The main issue here is that we create a detached signature (rather than
>> a clear text signature) but then lump it together with the content (the
>> tag object sans sig). The boundary mark between the two is not
>> controlled by us but by gpg (and its options).
>>
>> In order to verify the sig, *we* have to split the lump again but we
>> don't really know the boundary mark. It's insane by design. We should
>> have used a non-volatile boundary mark.
>>
>> I'll check whether we can somehow feed the whole lump to gpg and make it
>> recognize the attached-detached signature. That way we'd be as
>> compatible as gpg.
>>
>> Michael
>>
> 5 dashes + BEGIN [other stuff] and
> 5 dashes + END
> was part of RFC1991:
> http://tools.ietf.org/html/rfc1991#section-2.4.1
> 
> Which was obsoleted by RFC4880 :
> http://tools.ietf.org/html/rfc4880#section-6.2
> 5 dashes + BEGIN [some different stuff]
> 5 dashes + END
> 
> Aside from the above considerations, 5 dashes + BEGIN
> would appear to conform to both the old and the current spec. Since
> the current implementation of GnuPG only offers the rfc1991
> compatibility options, complying with both covers all (i.e. both)
> possibilties, no?

So, we (c|sh)ould really check for the two variants rather than being
lenient, right? I'll bite the v2 apple.

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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]