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

From: Shawn Pearce <spearce@spearce.org>
Date: Aug 26, 2014, 17:33 UTC
Message-ID: <CAJo=hJs3m-0u7NkPHJqvk4qZBGtPguck-xn=in3m-+30UxDQoA@mail.gmail.com>
In-Reply-To: <xmqqd2bomowm.fsf@gitster.dls.corp.google.com>

On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 17 quoted lines

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

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.