On 2025-04-13 at 19:17:26, Klaus Frank wrote: > Hi, Hi, > how do I get "git send-email" to send the patches gpg signed? I tried > first signing the commit but after spending time looking into the > documentation I couldn't work out how to do it. All I discovered so far > is that the "git send-email" appears to be using "git format-patch" > internally and that's where it currently gets lost. > > Sadly none of the man pages I looked at so far mentions anything about > gpg signing in this regards. Not even "git am" does. > > Ideally I'd like to have "git send-email" send my patches gpg-signed to > ensure authenticity and integrity. > > I also considered alternatives like using my MTA to GPG-Sign these mails > however as the "git am" documentation also didn't mention gpg signing I > refrained from it to avoid breaking it and causing issues for anyone > receiving that patch. Same for sending it using "git pack". > > Is this currently a limitation or am I just doing it wrong? I don't think Git supports this out of the box. The proper way to do this would be via PGP/MIME, since clearsigning the patches would result in them not applying properly (due to the dashes being escaped). More notably, I've had problems applying patches that are signed using PGP/MIME because `git am` doesn't seem to understand how to extract the data in all cases (maybe it does in some cases, but I haven't tested). As a practical matter, signing PGP/MIME requires that the enclosing body be encoded as either quoted-printable (recommended) or base64 (not recommended because plain text as base64 tends to be a sign of spam) because that prevents breakage from intervening mail servers and that can introduce some trickiness in extracting the text without parsing the MIME structure. I know that Git definitely does not know how to verify those signatures, though, so many people would end up not verifying them. The discussion on the list in the past has generally not been in favour of this approach, since the assumption is that the patch is accepted based on whether it is good or not and not whether it is authentic. I acknowledge that there are workflows where authenticity is useful, though, so I would not be opposed to seeing patches to implement this, but I'm afraid that it has yet to be implemented. An alternative approach, which has also been discussed (and which I might end up sending a patch for at some point), is including committer, signature, and base commit data in email headers to allow reconstructing the exact commit with a valid signature. Whether the maintainer chooses to keep that signature is of course up to them, but this would allow the commit to be verified using the normal mechanism. -- brian m. carlson (they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
