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