Re: [PATCH 00/18] Signed push

On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano [off-list ref] wrote:

If the server's GPG keychain and pre-receive hook are properly set
up, a "git push --signed" over an unauthenticated and unencrypted
communication channel (aka "git daemon") can be made as secure as,
and even more secure than, the authenticated "git push ssh://".

With the signed push certificate, together with the connectivity
check done when the server accepts the packed data, we are assured
that the trusted user vouches for the history leading to the
proposed tips of refs (aka "new-sha1"s), and a man-in-the-middle
would not be able to make the server accept an update altered in
transit.

The above was written long after the series was done, but rethinking
about it within that frame of mind helped me find one nit in the push
certificate design.

We would need a PKT-LINE("pushed-to" SP URL LF) in the header
part to prevent the certificate and the same set of refs from getting
replayed. Otherwise, a different repository that happens to have the
same set of refs with same set of old-sha1 values can be made to
accept a push that the signer never intended to make to it by replaying
an earlier push to a different site the signer did make.