Re: How to gpg signed email patches?

[Klaus Frank <vger.kernel.org@frank.fyi>]

On 2025-04-14 00:21:46, Matt Hunter wrote:
> 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)