On Thu, Sep 15, 2011 at 7:05 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Nguyen Thai Ngoc Duy wrote: >> On Wed, Sep 14, 2011 at 2:45 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >>> An alternative that I am considering is to let the requester say this >>> instead: >>> >>> are available in the git repository at: >>> git://git.kernel.org/pub/flobar.git/ 5738c9c21e53356ab5020912116e7f82fd2d428f > [...] >> Stupid question, if we agree to go with signed push, can we also sign >> pull requests and verify them when we pull? I suppose most of the >> time, pulling can be done automatically by extracting pull url from >> the request. This would make pull/push both signed. >> >> BTW, there's a third way (rsync is obsolete) to carry changes away in >> human-unreadable way: bundles. Should we also sign the bundles too (I >> guess we could just do the same as in signed push). > > If I understand you correctly, then ordinary PGP email signing[1] > should work for that already. In your first example, the receiver can > make sure whatever process grabs a pull request verifies it, and in > the second example, the receiver checks the signature on her email > before saving a bundle and passing it to "git fetch". Yes, I think we can do that already. It's just more convenient to teach "git fetch/pull" to take pull requests and automatically verify them. Some repositories may also want to enforce signing and we can do that by setting config file and fetch/pull refuses if pull requests are not signed. We can also store the sign as git notes, just like in git-push (extra work if it has to be done manually). > [1] http://www.phildev.net/pgp/gpgmua.html -- Duy -- 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