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 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

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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to