On Thu, Sep 4, 2014 at 4:57 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> As you know, the stateless HTTP thing doesn't allow the nonce on the
>> server to be carried from the initial ref advertisement into the final
>> receive-pack. We would either need to write the nonce to disk and loa
Shawn Pearce writes:
> As you know, the stateless HTTP thing doesn't allow the nonce on the
> server to be carried from the initial ref advertisement into the final
> receive-pack. We would either need to write the nonce to disk and load
> it back up later (ick), or use some sort of stateless non
Junio C Hamano writes:
> 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)?
Nah, that wa
Shawn Pearce writes:
> On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano wrote:
>> Shawn Pearce 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
>>>
On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano wrote:
> Shawn Pearce 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-pac
Shawn Pearce 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 wit
On Fri, Aug 22, 2014 at 10:59 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> There are a few gotchas I can certainly use help on, especially from
>> a smart-http expert ;-).
>>
>> * "pushed-to " will identify the site and the repository, so
>>you cannot MITM my push to an experiment
Junio C Hamano writes:
> There are a few gotchas I can certainly use help on, especially from
> a smart-http expert ;-).
>
> * "pushed-to " will identify the site and the repository, so
>you cannot MITM my push to an experimental server and replay it
>against the authoritative server.
>
On Thu, Aug 21, 2014 at 12:28 PM, Shawn Pearce wrote:
> On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano wrote:
>>
>> + push-cert = PKT-LINE("push-cert" NUL capability-list LF)
>
> Haha. NUL. I love our wire protocol.
It is a direct and natural consequence of [PATCH 02/18].
We could us
On Aug 21, 2014, at 16:40, Junio C Hamano wrote:
* The receiving end will issue "push-cert=" in its initial
capability advertisement, and this will be given on the
PUSH_CERT_NONCE environment to the pre/post-receive hooks, to
allow the "nonce " header in the signed certificate to be
che
On Tue, 2014-08-19 at 15:06 -0700, Junio C Hamano wrote:
>
> +If the receiving end does not support push-cert, the sending end MUST
> +NOT send a push-cert command.
> +
> +When a push-cert command is sent, command-list MUST NOT be sent; the
> +commands recorded in the push certificate is used ins
Shawn Pearce writes:
> On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano wrote:
>>
>> + push-cert = PKT-LINE("push-cert" NUL capability-list LF)
>
> Haha. NUL. I love our wire protocol.
>
>> + PKT-LINE("certificate version 0.1" LF)
>> + PKT-LINE("p
On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano wrote:
>
> + push-cert = PKT-LINE("push-cert" NUL capability-list LF)
Haha. NUL. I love our wire protocol.
> + PKT-LINE("certificate version 0.1" LF)
> + PKT-LINE("pusher" ident LF)
> +
With the interim protocol, we used to send the update commands even
though we already send a signed copy of the same information when
push certificate is in use. Update the send-pack/receive-pack pair
not to do so.
The notable thing on the receive-pack side is that it makes sure
that there is no
14 matches
Mail list logo
