Re: git-send-email with GPG signed commits?

From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Date: Oct 20, 2022, 18:55 UTC
Message-ID: <20221020185552.la6ewgjre7dlq6xx@meerkat.local>
In-Reply-To: <a2b0abfa-3533-b22b-1e8f-5be4c00163ce@cepl.eu>

On Thu, Oct 20, 2022 at 07:29:35PM +0200, Matěj Cepl wrote:

Show 14 quoted lines

> > Linux Kernel supports end-to-end attested patches (including using PGP), but
> > the implementation took a slightly different direction, because there are
> > important downsides to PGP-signed messages when it comes to patch workflows.
> > 
> > See the following project:
> > https://pypi.org/project/patatt/
> 
> Hmm, that's very interesting and it seems that at least somehow sr.ht has to
> work with (https://is.gd/qea0gF), but if I understand it correctly the GPG
> signature is on the email, not on the commit, so git-am(1) (or even b4
> shazam) sees just unsigned commit and when pushed to GitHub/GitLab or any
> other repository which knows about signing git commits, it doesn’t get green
> check-mark, right? Although, the line “you can use PGP keys to sign git
> tags/commits, not just mailed patches” in the README makes me wonder.

No, you are correct, these signatures are not carried into git commits, because the commit message is almost always modified to insert the Signed-off-by or other trailers, which invalidates the git commit signature.

The goal of patatt signatures is precisely to attest *patches* and operate completely independently from in-git signatures.

> Hmm, I should probably ask on the sr.ht list.

In my previous interactions with Drew, he was not really interested in this work. I know that sr.ht does check DKIM signatures on incoming patches, so it does have domain-level attestation.

Regards, Konstantin