Re: [Survey] Signed push

From: Jeff King <peff@peff.net>
Date: Sep 15, 2011, 17:50 UTC
Message-ID: <20110915175050.GA20495@sigill.intra.peff.net>
In-Reply-To: <CACsJy8BEES2j8K1v23RQQS=R1vRm1SVizBGFzq0wsDcMvC6Fjw@mail.gmail.com>

On Thu, Sep 15, 2011 at 08:42:40AM +1000, Nguyen Thai Ngoc Duy wrote:

Show 6 quoted lines

> 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