Re: git-send-email with GPG signed commits?

From: Jeff King <peff@peff.net>
Date: Oct 20, 2022, 18:31 UTC
Message-ID: <Y1GUDbtFIGZu0BKD@coredump.intra.peff.net>
In-Reply-To: <xmqqk04us77b.fsf@gitster.g>

On Thu, Oct 20, 2022 at 11:03:52AM -0700, Junio C Hamano wrote:

Show 9 quoted lines

> Junio C Hamano <gitster@pobox.com> 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?

Oops, you're right. The parent pointer in subsequent ones is unknowable.

Show 5 quoted lines

> 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.

No, I was not that clever. I just didn't think about the subsequent commits. I agree that an author-sig that omits the parent pointer is practically useless. It does record the end tree state faithfully, but what most people consider interesting in a commit is the diff from the parent tree. So applied in the wrong spot, it makes it look like your signed commit made changes you never intended.

Show 13 quoted lines

> 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.

I think it's a bit weird if parent-tree does not match the first parent. Your final tree must still match what was signed. And so if you applied it on a commit that didn't match the original parent-tree, then the commit would be quietly reverting changes between the original parent-tree and the actual parent it was applied on.

I do think it would work if you enforced that. But I tend to agree with your other comment that people may be better off just sending bundles at that point.

> 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.

Yes, like bundles, it is losing some of the flexibility of an emailed-patch workflow. I haven't played with b4's attestation too much, but I think it slots into a patch workflow better. You are signing the patch, not the commit, and commits which are made later can refer back to the emails, which people can then verify. That's not a signature on the commit, but it is a paper trail that can be followed.

-Peff