Re: [PATCH 18/18] signed push: final protocol update

[Junio C Hamano <gitster@pobox.com>]

Shawn Pearce <spearce@spearce.org> writes:

> On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Shawn Pearce <spearce@spearce.org> writes:
>>
>>> A stateless nonce could look like:
>>>
>>>   nonce = HMAC_SHA1( SHA1(site+path) + '.' + now, site_key )
>>>
>>> where site_key is a private key known to the server. It doesn't have
>>> to be per-repo.
>>>
>>> receive-pack would then be willing to accept any nonce whose timestamp
>>> is within a window, e.g. 10 minutes of the current time, and whose
>>> signature verifies in the HMAC. The 10 minute window is important to
>>> allow clients time to generate the object list, perform delta
>>> compression, and begin transmitting to the server.
>>
>> Hmph, don't you send the "finally tell the other end" the sequence
>> of "update this ref from old to new" and the packdata separately?
>
> No. The command list (triples of old, new, ref) is sent in the same
> HTTP request as the pack data, ahead of the pack data. So its one
> request.

That is unfortunate.  Would it be a major surgery to update the
protocol not to do that, perhaps by moving the command list from 3
to 2 (the latter of which is not currently doing anything useful
payload-wise, other than flushing a HTTP request early)?

> Push on smart HTTP is 3 HTTP requests:
>
>   1)  get advertisement
>   2)  POST empty flush packet to tickle auth (literally just "0000").
>   3)  POST command list + pack
>
> The nonce can be sent server->client in 1, and client->server in 3.
>
>>  I
>> think we have a FLUSH in between, and the push certificate is given
>> before the FLUSH, which you do not have to wait for 10 minutes.
>
> Nope I think you need to wait for the pack to generate enough to start
> sending the pack data stream. Nothing forces the smart HTTP client to
> push its pending buffer out. We wait for the pack data to either
> finish, or overflow the in-memory buffer, and then start transmitting.
> If your client needs a lot of time for counting and delta compression,
> we aren't likely to overflow and transmit for a while.
>
> If you send a _lot_ of refs you can overflow, which will cause us to
> transmit early. But we are talking about megabytes worth of (old, new,
> ref) triplets to reach that overflow point.