The person requesting the pull signs the pull request by signing the git tag. The GPG signature on the git tag covers the complete history of up to that point in the tag, so there's no need to sign each and every git commit, as you propose. When the upstream maintainer (or Linus, at the top level) accepts the pull request, git will automatically create a merge request that contains a copy of the git tag's GPG signature in the merge request. (After this point, the git tag can be discarded). When Linus releases something, he signs a git tag for the overall git repository, and everyone can check that.

So for example, when I am satisfied that everything in the ext4 tree that I want to push to Linus is OK, I create a signed tag named "ext4_for_linus", and send him a git pull request, which is created using the "git request-pull" command. This creates an e-mail message contains the URL of my git repository and the name of the signed tag. When Linus accepts my pull request, the resulting merge commit will contain a copy of my GPG signature from the git tag. This signature signs my name to the commit id of the git tag, and the chain of SHA-1 hashes inherent in git guarantees that the entire commits back to the beginning of time came from me. Of course, my changes will branch of something like v3.3-rc2, which is in Linus's tree, so what is being signed that is of interest is my new changes between v3.3-rc2 and the tip of the ext4 tree.

Once Linus has accepted my pull, I'll reuse the ext4_for_linus name for the next GPG-signed tag for the next 2-3 month development cycle, since the important bit (the GPG signature) is preserved for long-term posterity in the merge commit. But what's important to note here is that the signature in the merge commit is signed by me, since it contains the contents of what I pushed to Linus, even though the merge commit was created by Linus when he accepted the pull request by merging in my changes into the repository. What Linus signs is the GPG tag for the actual released kernel (i.e., v3.3).

See? So there's no need to refer to the mailing list to validate the pull request or to establish after-the-fact accountability. The mailing list is just used for review purposes. But of course the review is a critical part of the acceptance process.

Ah, I see. Thank you for the clarification.

It was not overall integrity of the trees that I was bringing into question. While the code review process may be a problem for certain organizations, I am not doubting that process for the kernel. With such a process in place, signed tags are likely to be sufficient, yes.

Note, however, that one of the points I was trying to make with the article was proof of authorship (to prevent someone from committing as you, much the same way as you would want to prevent someone from fraudulently sending an e-mail or message through any other means). It is for this reason that the workflow you described is not a complete alternative, but would be an excellent means of augmenting the review process for any project.

That said, author identity is not a concern for most projects, in which case, based on the quoted portion of your comment above, my arguments do not necessarily apply (assuming that all commits that are not yet ancestors of a tag are ancestors of a signed merge, as mentioned in your comment).

Might I ask how the maintainers deal with issues of identity? If they encounter a commit in your pull request that appears to be from a well-known contributor, do they verify his/her identity before merging, or do they not care?

But that's only important from the perspective of knowing that a particular public key belongs to a person, which in turn is only really important when a maintainer wants to know whether or not the person who signed the git tag really is the submaintainer who is claiming to have signed the git tag.

Most of the time, we don't really worry about identity; what we worry about is the correctness of the commit. Especially for patches being sent via e-mail, I really couldn't care less whether the identity of the person sending the e-mail was Christoph Hellwig, or his evil twin. I'm still going to review the patch very carefully, because we all make mistakes. That's my job as the maintainer; to ultimately be a crap filter, and to reject crap, no matter whether it's written by someone famous or some nobody.

So when I send a pull request to my upstream maintainer (which in the case of ext4 is Linus), he really doesn't care about the identities of the authors in my pull request, because it is my reputation which is on the line; I'm the one who signed the git tag pointed to by the pull request. Just if it gets by me, and then it gets by Linus, it's ultimately Linus's reputation which is on the line.

So that's why your question is a bit ill-formed. Someone who is above me in the maintainership hierarchy isn't really going to care much about the identities of those who are below me in the maintainership hierarchy. The trust relationship is fundamentally between me and Linus, and then I have trust relationships between me and those developers below me. So Linus doesn't care about the identities of those which are two levels below him in the maintainership hierarchy, so long as he trusts me to have done my job properly. Of course, if Linus discovered that I had been blindly accepting pull requests from my downstream without doing proper quality control, then he'll yell at me and he might refuse to take future pull request from me (or at least threaten to do so). But normally, there's no need for him to verify the identity of the authors of commits in my pull request; he only needs to verify me, and to verify that he trusts my technical judgement and quality control checks and processes. If decides he doesn't trust me or my technical judgement then he won't accept pull requests from me; and in that case he would be absolutely right to do so.