On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano <gitster@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html