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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Shawn Pearce <spearce@xxxxxxxxxxx> 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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]