From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 22 Aug 2014 17:59:56 GMT
Subject: Re: [PATCH 18/18] signed push: final protocol update
Message-ID: <xmqqa96wpfqb.fsf@gitster.dls.corp.google.com>
In-Reply-To: <xmqqvbplpg2s.fsf@gitster.dls.corp.google.com>

Junio C Hamano <gitster@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.