On Thu, Sep 15, 2011 at 08:42:40AM +1000, Nguyen Thai Ngoc Duy wrote:
> 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).
Isn't there a human element in the verification? I.e., I see a pull
request, and we can computationally verify that it is signed by some
key. Now assuming GPG's web of trust works, that binds that key to an
email address and a real name. But how is that bound to the repository
you are actually fetching from (or more appropriately, that the commits
mentioned are appropriate to be pulled)?
That is a policy that the human must decide upon seeing "Oh, a pull
request from developer X; I should pull that into my local branch Y",
and which they do implicitly when they manually run the pull command
mentioned in the email.
Another way to think of it is that verifying the identity of the sender
(which GPG does) is only one step. You also need an ACL saying that the
sender is worth pulling from.
So either:
1. The human is still in the loop, in which case having git-pull
verify the sender's identity hasn't really done anything (because
probably their MUA already told them it was really from the
purported sender, and then they made the ACL decision in their head
before deciding to pull from you).
2. The human is not in the loop, and nothing is checking that ACL.
-Peff
--
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