Junio C Hamano <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
