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

From: Kyle J. McKay <mackyle@gmail.com>
Date: Aug 22, 2014, 03:06 UTC
Message-ID: <1C5353D0-E5E1-466B-855E-2E5D8A54AE93@gmail.com>
In-Reply-To: <xmqqvbplpg2s.fsf@gitster.dls.corp.google.com>

On Aug 21, 2014, at 16:40, Junio C Hamano wrote:

Show 13 quoted lines

> * 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 to be
>   checked against it.  You cannot capture my an earlier push to the
>   authoritative server and replay it later.
>
>   That would all work well within a single receive-pack process,
>   but with "stateless" RPC, it is unclear to me how we should
>   arrange the <nonce> the initial instance of receive-pack placed
>   on its capability advertisement to be securely passed to the
>   instance of receive-pack that actually receives the push
>   certificate.

Have you considered having the advertised nonce only be updated after receipt of a successful signed push?

It would eliminate the stateless issue. And since the next nonce to be advertised would be updated at the successful completion of a receive of a signed push no replay would be possible. (I'm assuming that receive hook activity is already pipelined in the case of simultaneous pushes via some lock file or something or this scheme falls apart.)

The obvious downside is that only one of two or more simultaneous signed pushers could succeed. But the sender could be modified to automatically retry (a limited number of times) on a nonce mismatch error.

A receive hook could also be responsible for generating the next nonce value using this technique.