Re: [PATCH 3/7] pack-protocol.txt: Mark all LFs in push-cert as required

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 6, 2015, 16:57 UTC
Message-ID: <xmqq615x2ph1.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAD0k6qRLu1d7Sa8aVrHtDCsJNtVXwzHBAyOmmUHmVAx7qHmOPg@mail.gmail.com>

Dave Borowitz <dborowitz@google.com> writes:

> The server can munge pkt-lines and reinsert LFs, but it _must_ have
> some way of reconstructing the payload that the client signed in order
> to verify the signature. If we just naively insert LFs where missing,
> we lose the ability to verify the signature.

I still do not understand this part.

There is no way to "naively" insert, is there? You have an array of lines (each of which you have already stripped its terminating LF at its end). How else other than adding one LF at the end of each element do you reconstruct the original multi-line string the client signed? Are there other ways that makes the result ambiguous??

Show 7 quoted lines

> If we say the payload the client signs MUST have LFs only in certain
> places, then that gives the server enough information to reconstruct
> the payload and verify the signature.
>
> But if we say the signed payload MUST have LFs and the wire payload
> MAY have LFs, then now we have two completely different formats, only
> one of which is documented.

I thought that was what I was saying. The wire protocol sends the contents of each line (both what is signed and the signature) on a separate packet. When I say "contents of a line", I do not include the terminating LF as part of the line (iow, LF is not even optional; the terminating LF is not considered as part of "the contents of a line"). It becomes irrelevant that a pkt-line may or may not have a trailing optional LF. If there is LF at the end of a packet between "push-cert" and "push-cert-end" packets, that LF by definition cannot be part of the "contents of a line" in a certificate.

It is just a pkt-line framing artifact you can and should remove if you are doing a "split to array, join with LF" implementation to recover the original string.

And that is very much consistent with the way we send other things with pkt-line protocol. Each packet up to the first flush is expected to have <object name> and <refname> as ref advertisement. The pkt-line framing may or may not add a trailing LF, but LF is not part of <refname>. It is not even part of the payload; merely an artifact of pkt-line framing.