Re: How to gpg signed email patches?
- From
brian m. carlson <sandals@crustytoothpaste.net>
- Date
- Apr 14, 2025, 00:48 UTC
- Message-ID
- <Z_xbUDk7ra1-d_gH@tapette.crustytoothpaste.net>
- In-Reply-To
- <0709104c-c951-42be-9300-a0aa9f9eea6c@frank.fyi>
On 2025-04-14 at 00:23:02, Klaus Frank wrote:
> But if "git am" would support pgp clearsigning it could just easily reverse > that, no?
Yes, but not everybody has GnuPG installed on their system. It doesn't come by default on macOS and people will want to parse the emails and apply the patches nonetheless.
> But I've to admit I didn't fully look into all of the escape rules and their > reversability yet. Is RFC 4880 Section-7 the correct one for clearsign > and RFC 3156 Section-5 the correct one for PGP/MIME?
Yes, although RFC 9580 has superseded RFC 4880.
> That may be, however the signature also shows if it has been damaged > in transit and that is at least in my eyes a very valuable information. > (And maybe in the near future to mandate everyone signs (or even > encrypt) their contributions in order to easily ban "vibe coders")
I agree that it detects patches that have been damaged in transit, which is valuable, but it also throws a bunch of complexity into the process.
Show 9 quoted lines
> > > 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. > > That sounds also good compared to what I scetched up so far. > This is what I was thinking about btw (nothing special really):
My approach also has the benefit that it works for SSH commit signatures, which PGP/MIME and S/MIME do not. I think many people find SSH signatures to be easier to use than OpenPGP or X.509 and SSH signing is easier to do when one's working in a remote dev environment (just forward your agent).
Show 13 quoted lines
> On the sender side:
> 1. "git format-patch"/"git send-email" sees that the commit{s} is/are signed
> or it was executed with an explicit flag to sign (similar to git-commit
> "-S[<key-id>], --gpg-sign[=<key-id>], --no-gpg-sign")
> 2. Either "git format-patch":
> a. Somehow embedds the commit signature as plain text [Your suggestion].
> b. Does "gpg --sign --clear-sign --include-key-block" the entire email (Or
> [rfc4880#section-7]).
> c. When "--inline" is specified {multipart message} it creates a detached
> signature ("gpg --sign --detach-sign --include-key-block --armor") and
> attach it as a 3rd "application/pgp-signature" part to the multipart-message
> (or [RFC3156#Section-5] instead of literally "just" attaching an additional
> .sig file to the mail)This isn't the entirety of how it works. I believe the headers of the internal part (e.g., Content-Type and Content-Transfer-Encoding) are also signed in PGP/MIME; that is, it's the entire body part, headers and all.
> 3. Send the mail > Also "git format-patch" propably should support these gpg commandline > properties: `--homedir`, `--keyring`, `--primary-keyring`, `--refresh-keys`, > `--armor`, `--no-armor`.
Those arguments are really better left to a script that runs as `gpg.program`. There are other implementations of that software that only support the bare minimum options (e.g., smimesign) and we want to minimize the functionality that needs to be supported. I have, for instance, used a custom script to include a signature from the environment that was generated on another machine.
That's another advantage to my approach: it avoids the necessity for additional options to be supported.
-- brian m. carlson (they/them) Toronto, Ontario, CA