On Mon, Jul 6, 2015 at 12:28 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> writes:
>
>> push cert format is like commit or tag format. You need those LFs. We
>> can't just go declare them optional because of the way pkt-line read
>> function is implemented in git-core.
>
> As I said, I view each of the packets between "push-cert" and
> "push-cert-end" packets representing the meat of each line in the
> cert. The sending end takes a cert as a long multi-line string,
> splits them into an array, each of whose element represents a line
> in it (iow "certlines = certstring.split('\n')"), and sends them
> packetised.
Right now the sending end sends newlines.
> The receiver receives a sequence of packets, notices "push-cert"
> packet, collects packets until it sees "push-cert-end" packet and
> treats them as elements of this array. pkt-line deframing process
> would have to strip optional LFs to reconstruct the original array
> the sender had (i.e. the above certlines array).
The problem is the signature. Today, the client computes the signature
over the payload it actually sends (minus pkt-line headers)
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.
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.
> The receiver needs to join the array with LF to recover the long
> multi-line string once it received the array. But this LF does not
> have anything to do with the optional trailing LF in pkt-line. If
> you sent the original "certlines" array via different RPC mechanism,
> you need to join them together with your own LF to reconstruct the
> multi-line string.
>
--
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