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

[Junio C Hamano <gitster@pobox.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??

> 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.