On 2025-04-14 00:52:42, brian m. carlson wrote:
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?
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. :/
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")
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
