Re: How to gpg signed email patches?

From: Klaus Frank <vger.kernel.org@frank.fyi>
Date: Apr 13, 2025, 23:12 UTC
Message-ID: <fba4f0a0-3ca8-455c-bfb8-70118de89fad@frank.fyi>
In-Reply-To: <D95V0Z9YMEX2.3J99CE4F6ZP8S@lfurio.us>

On 2025-04-14 00:21:46, Matt Hunter wrote:

Show 5 quoted lines

> Hi
> There's a conceptual issue with mailing patches from signed commits.
> Once your patch recipient goes to apply it to their branch, they are
> recorded as the "committer" identity of the new commit object.  This
> would break the validity of any existing signature.

You're right on that part. However even though it would be nice to get the signed commit into the public repo my main focus here was more to ensure integrity and authenticity until it is processed by the project maintainers. E.g. it didn't get mangled by some thing on the way and I wasn't impersonated by someone else. E.g. I was mainly focusing on allowing the ones accepting my patch to know it is from me and it hasn't been tampered with on the way. E.g. by a mail server screwing with the mail content or some middle box that inserted or rewrote parts of the message...

> This is likely the reason by the related git tools (format-patch, am)
> ignore this information.

Ok, how do others deal with that scenario then? Not an issue?

> You may have also noticed that commands like git-rebase and
> git-cherry-pick will drop signatures from commits as well, since they
> are being replayed onto a different history, changing the commit data.

True, but thouse commands to not pass information through a lossy and "tampery" media like email. It stays local. My main focus was on the transfer from my git repo to the (git repo of) other devs on the project. And lesser on it being preserved after the merge.

When a project uses a forge like github or gitlab this is basically not such an issue because of TLS and having to have a user account on it (and it preserving the pgp signature up until the last click before being merged in)