Junio C Hamano <gitster@xxxxxxxxx> writes: >> I think you would need some kind of "author-sig" header that signs the >> commit object bytes _without_ the commit header at all. And that assumes >> the maintainer's workflow is to never modify a patch in transit, and to >> apply it at the exact same spot that you wrote it (so that the parent >> and tree ids remain the same). > > Doesn't it immediately break down once you send a 2-patch series? Ah, if you did not mean "without the committer header", but "without any of the header fields of the commit object", then it would probably work. But then that loses the context to apply the patch completely, so I can apply a patch you author-signed to a place where it wouldn't work and end up with a broken commit. Start from the original commit object, remove the committer, the author, the tree, and the parent headers, add a parent-tree header that records the tree object of the first parent, and call that a "modified commit object". Then compute the signature over it and the patch text. The e-mailed patch now needs to carry the value of the parent-tree header and the signature. At the receiving end, the reverse operation can be done and the resulting commit may have two new headers (author-sig and parent-tree). In the resulting commit, parent-tree does not have to match the tree of its first parent, if the integrator chose to apply it on a different commit, and as long as the patch text matches, things should verify. So, some kind of "author-sig" is certainly possible, but is it practically useful? I am not sure. It still does not even allow typofixes on the receiving end.
