Shawn Pearce spea...@spearce.org 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
On Thu, Sep 4, 2014 at 4:57 PM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@spearce.org 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
On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@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
Shawn Pearce spea...@spearce.org writes:
On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano gits...@pobox.com wrote:
Shawn Pearce spea...@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
Junio C Hamano gits...@pobox.com 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)?
Shawn Pearce spea...@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
Junio C Hamano gits...@pobox.com writes:
There are a few gotchas I can certainly use help on, especially from
a smart-http expert ;-).
* pushed-to URL will identify the site and the repository, so
you cannot MITM my push to an experimental server and replay it
against the
On Fri, Aug 22, 2014 at 10:59 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
There are a few gotchas I can certainly use help on, especially from
a smart-http expert ;-).
* pushed-to URL will identify the site and the repository, so
you cannot MITM
On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano gits...@pobox.com 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)
+
Shawn Pearce spea...@spearce.org writes:
On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano gits...@pobox.com 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)
+
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 instead.
On Aug 21, 2014, at 16:40, Junio C Hamano wrote:
* The receiving end will issue push-cert=nonce in its initial
capability advertisement, and this nonce will be given on the
PUSH_CERT_NONCE environment to the pre/post-receive hooks, to
allow the nonce nonce header in the signed certificate
On Thu, Aug 21, 2014 at 12:28 PM, Shawn Pearce spea...@spearce.org wrote:
On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano gits...@pobox.com 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
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
