Re: How to gpg signed email patches?

From: Klaus Frank <vger.kernel.org@frank.fyi>
Date: Apr 14, 2025, 00:23 UTC
Message-ID: <0709104c-c951-42be-9300-a0aa9f9eea6c@frank.fyi>
In-Reply-To: <Z_xAOmQm0e_WE2Dd@tapette.crustytoothpaste.net>

On 2025-04-14 00:52:42, brian m. carlson wrote:

Show 6 quoted lines

> On 2025-04-13 at 19:17:26, Klaus Frank wrote:
>> Hi,
>>
>> 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).

But if "git am" would support pgp clearsigning it could just easily reverse that, no? 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?

Show 12 quoted lines

>> 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.

Yea, then better just not include them for now. Including them sounds like a shitty move towards or better against the other developers. Kinda but not quite maliciouse compliance style. :/

Show 6 quoted lines

>> 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.

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")

Show 6 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):

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)
3. Send the mail
Also "git format-patch" propably should support these gpg commandline 
properties: `--homedir`, `--keyring`, `--primary-keyring`, 
`--refresh-keys`, `--armor`, `--no-armor`.

On the receiver side when running e.g. "git am": On a mail without a signature => Fallback to current behaviour accept (maybe have an optional configurable warning message). And have an option to enforce signatures (fail if enforced and missing). On a mail with a signature: a. If nothing else specified default to e.g. `gpg --verify --batch --auto-key-import --auto-key-retrieve --tofu-default-policy="auto" --trust-model="tofu+pgp"` (marginally trust all keys and build a web of trust; Maybe on a dedicated gpg-homedir/keyring) b. If operating on the users generic gpg-homedir/keyring or explicitly specified use `--tofu-default-policy="unknown"` instead of "auto". This will still import and validate keys from the signatures [depending on user system config also from keyserver, ldap, ... but disabled by default] but any key the user didn't touch themselves will be considered "unknown" trusted and therefore won't be used for extending the web of trust. c. also have flags for these gpg commandline properties: `--homedir`, `--keyring`, `--primary-keyring`, `--refresh-keys`. d. maybe also add pgp-encryption support (to also accept e.g. patches for zero days?). All that would be needed for that is "git am" would have to tell gpg to try to decript the message and similar "git format-patch" would need one to encrypt.

Sincerely, Klaus Frank