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 authoritative server. > > However, the receiving end may not even know what name its users > call the repository being pushed into. Obviously gethostname() > may not be what the pusher called us, and getcwd() may not match > the repository name without leading "/var/repos/shard3/" path > components stripped, for example. > > I am not sure if we even have the necessary information at > send-pack.c::send_pack() level, where it already has an > established connection to the server (hence it does not need to > know to whom it is talking to). > > > * 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.
A good <nonce> may be something like taking the SHA-1 hash of the concatenation of the sitename, repo-path and the timestamp when the receive-pack generated the <nonce>. Replaying a push certificate for a push to a repository at a site that gives such a <nonce> can succeed at the same chance of finding a SHA-1 collision [*1*]. As long as you exercise good hygiene and only push to repositories that give such <nonce>, we can do without checking "pushed-to" that says where the push went. So "nonce <nonce>" is the only thing that is necessary to make them impossible to replay. For auditing purposes, "pushed-to <URL>" that records the repository the pusher intended to push to may help but probably not necessary [*2*]. [Footnote] *1* And the old-sha1s recorded in the certificate has to match what the repository being attacked currently has; otherwise the push will fail with "the ref moved while you were trying to push". *2* When auditing the history for a repository at a site, the certificate the auditors examine would be the ones accumulated at that site for the repository, so we would implicitly know the value for <URL> already. -- 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