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.
> > > 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).
> 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
Attachment:
signature.asc
Description: PGP signature
