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

Shawn Pearce [off-list ref] writes:

On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano [off-list ref] wrote:

quoted

Shawn Pearce [off-list ref] writes:

quoted

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.

quoted

 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.