git-send-email with GPG signed commits?

git-send-email with GPG signed commits?

[Matěj Cepl]

[-- Attachment #1.1.1: Type: text/plain, Size: 708 bytes --]

Hello,

did anybody even think about %subj%? Is there some effort somewhere 
making git-send-email(1) supporting transfer of signed commits, where I 
could join? I like hosting sites like sr.ht, which support 
git-send-email(1), but unfortunately using that clears my submission off 
its GPG signatures. I guess, it would be necessary to make some 
modifications to git-send-email(1) and git-am(1). Is there some effort 
somewhere in that direction?

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Somewhere at the edge of the Bell curve was the girl for me.
     -- Based on http://xkcd.com/314/

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7229 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Konstantin Ryabitsev]

On Thu, Oct 20, 2022 at 06:26:49AM +0200, Matěj Cepl wrote:
> Hello,
> 
> did anybody even think about %subj%? Is there some effort somewhere making
> git-send-email(1) supporting transfer of signed commits, where I could join?
> I like hosting sites like sr.ht, which support git-send-email(1), but
> unfortunately using that clears my submission off its GPG signatures. I
> guess, it would be necessary to make some modifications to git-send-email(1)
> and git-am(1). Is there some effort somewhere in that direction?

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/

There is a section on that page that describes why PGP-signed patches aren't
the preferred way to go for many people.

Best regards,
Konstantin

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

[Matěj Cepl]

[-- Attachment #1.1.1: Type: text/plain, Size: 1754 bytes --]

Dne 20. 10. 22 v 14:46 Konstantin Ryabitsev napsal(a):
>> did anybody even think about %subj%? Is there some effort somewhere making
>> git-send-email(1) supporting transfer of signed commits, where I could join?
>> I like hosting sites like sr.ht, which support git-send-email(1), but
>> unfortunately using that clears my submission off its GPG signatures. I
>> guess, it would be necessary to make some modifications to git-send-email(1)
>> and git-am(1). Is there some effort somewhere in that direction?
> 
> 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.

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

Thank you for the response,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

в чужой монастырь со своим уставом не ходят.
     -- Russian proverb (this time actually checked by a native
        Russian)


[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7229 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[Konstantin Ryabitsev]

On Thu, Oct 20, 2022 at 07:29:35PM +0200, Matěj Cepl wrote:
> > 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

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

[Jeff King]

On Thu, Oct 20, 2022 at 06:26:49AM +0200, Matěj Cepl wrote:

> did anybody even think about %subj%? Is there some effort somewhere making
> git-send-email(1) supporting transfer of signed commits, where I could join?
> I like hosting sites like sr.ht, which support git-send-email(1), but
> unfortunately using that clears my submission off its GPG signatures. I
> guess, it would be necessary to make some modifications to git-send-email(1)
> and git-am(1). Is there some effort somewhere in that direction?

I think there's an inherent problem here. A commit signature is over the
entire commit object. But when you send a patch, you don't know the
exact bytes of the resulting commit object. In particular, the
"committer" line will have the ident and timestamp from when the
receiver applies the patch and turns it into a commit.

So commit signatures are generally an attestation by the committer, not
by the author. It's just that the two are usually the same when you are
committing locally.

I think you would need some kind of "author-sig" header that signs the
commit object bytes _without_ the commit header at all. And that assumes
the maintainer's workflow is to never modify a patch in transit, and to
apply it at the exact same spot that you wrote it (so that the parent
and tree ids remain the same).

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> So commit signatures are generally an attestation by the committer, not
> by the author. It's just that the two are usually the same when you are
> committing locally.
>
> I think you would need some kind of "author-sig" header that signs the
> commit object bytes _without_ the commit header at all. And that assumes
> the maintainer's workflow is to never modify a patch in transit, and to
> apply it at the exact same spot that you wrote it (so that the parent
> and tree ids remain the same).

Doesn't it immediately break down once you send a 2-patch series?
You may be able to get the bottom one right, but the top one needs
to depend on the commit object name of the result of applying the
bottom one.

It depends on what they are trying to achieve by transferrring with
existing signature intact.  If they truly want to preserve the
validity of the signatures on commits, they are better off
exchanging bundles over e-mail, as reviewers and integrators are not
even allowed to touch anything.

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>> I think you would need some kind of "author-sig" header that signs the
>> commit object bytes _without_ the commit header at all. And that assumes
>> the maintainer's workflow is to never modify a patch in transit, and to
>> apply it at the exact same spot that you wrote it (so that the parent
>> and tree ids remain the same).
>
> Doesn't it immediately break down once you send a 2-patch series?

Ah, if you did not mean "without the committer header", but "without
any of the header fields of the commit object", then it would
probably work.  But then that loses the context to apply the patch
completely, so I can apply a patch you author-signed to a place
where it wouldn't work and end up with a broken commit.  

Start from the original commit object, remove the committer, the
author, the tree, and the parent headers, add a parent-tree header
that records the tree object of the first parent, and call that a
"modified commit object".  Then compute the signature over it and
the patch text.  The e-mailed patch now needs to carry the value of
the parent-tree header and the signature.

At the receiving end, the reverse operation can be done and the
resulting commit may have two new headers (author-sig and
parent-tree).  In the resulting commit, parent-tree does not have to
match the tree of its first parent, if the integrator chose to apply
it on a different commit, and as long as the patch text matches,
things should verify.

So, some kind of "author-sig" is certainly possible, but is it
practically useful?  I am not sure.  It still does not even allow
typofixes on the receiving end.

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

[Jeff King]

On Thu, Oct 20, 2022 at 11:03:52AM -0700, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> >> I think you would need some kind of "author-sig" header that signs the
> >> commit object bytes _without_ the commit header at all. And that assumes
> >> the maintainer's workflow is to never modify a patch in transit, and to
> >> apply it at the exact same spot that you wrote it (so that the parent
> >> and tree ids remain the same).
> >
> > Doesn't it immediately break down once you send a 2-patch series?

Oops, you're right. The parent pointer in subsequent ones is unknowable.

> Ah, if you did not mean "without the committer header", but "without
> any of the header fields of the commit object", then it would
> probably work.  But then that loses the context to apply the patch
> completely, so I can apply a patch you author-signed to a place
> where it wouldn't work and end up with a broken commit.

No, I was not that clever. I just didn't think about the subsequent
commits. I agree that an author-sig that omits the parent pointer is
practically useless. It does record the end tree state faithfully, but
what most people consider interesting in a commit is the diff from the
parent tree. So applied in the wrong spot, it makes it look like your
signed commit made changes you never intended.

> Start from the original commit object, remove the committer, the
> author, the tree, and the parent headers, add a parent-tree header
> that records the tree object of the first parent, and call that a
> "modified commit object".  Then compute the signature over it and
> the patch text.  The e-mailed patch now needs to carry the value of
> the parent-tree header and the signature.
> 
> At the receiving end, the reverse operation can be done and the
> resulting commit may have two new headers (author-sig and
> parent-tree).  In the resulting commit, parent-tree does not have to
> match the tree of its first parent, if the integrator chose to apply
> it on a different commit, and as long as the patch text matches,
> things should verify.

I think it's a bit weird if parent-tree does not match the first parent.
Your final tree must still match what was signed. And so if you applied
it on a commit that didn't match the original parent-tree, then the
commit would be quietly reverting changes between the original
parent-tree and the actual parent it was applied on.

I do think it would work if you enforced that. But I tend to agree with
your other comment that people may be better off just sending bundles at
that point.

> So, some kind of "author-sig" is certainly possible, but is it
> practically useful?  I am not sure.  It still does not even allow
> typofixes on the receiving end.

Yes, like bundles, it is losing some of the flexibility of an
emailed-patch workflow. I haven't played with b4's attestation too much,
but I think it slots into a patch workflow better. You are signing the
patch, not the commit, and commits which are made later can refer back
to the emails, which people can then verify. That's not a signature on
the commit, but it is a paper trail that can be followed.

-Peff

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

[Konstantin Ryabitsev]

On Thu, Oct 20, 2022 at 02:31:41PM -0400, Jeff King wrote:
> Yes, like bundles, it is losing some of the flexibility of an
> emailed-patch workflow. I haven't played with b4's attestation too much,
> but I think it slots into a patch workflow better. You are signing the
> patch, not the commit, and commits which are made later can refer back
> to the emails, which people can then verify. That's not a signature on
> the commit, but it is a paper trail that can be followed.

That is accurate -- I've looked into attempting to preserve git commit
signatures via sent patches, precisely so they could be applied back into the
tree. However, the consensus among developers was that this is almost never
useful, and since we were already providing a robust paper-trail framework in
the form of public-inbox archives, it made sense to keep patch-level
attestation and git-level attestation separate.

-K

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

[rsbecker]

On October 20, 2022 3:01 PM, Konstantin Ryabitsev wrote:
>On Thu, Oct 20, 2022 at 02:31:41PM -0400, Jeff King wrote:
>> Yes, like bundles, it is losing some of the flexibility of an
>> emailed-patch workflow. I haven't played with b4's attestation too
>> much, but I think it slots into a patch workflow better. You are
>> signing the patch, not the commit, and commits which are made later
>> can refer back to the emails, which people can then verify. That's not
>> a signature on the commit, but it is a paper trail that can be followed.
>
>That is accurate -- I've looked into attempting to preserve git commit signatures via
>sent patches, precisely so they could be applied back into the tree. However, the
>consensus among developers was that this is almost never useful, and since we
>were already providing a robust paper-trail framework in the form of public-inbox
>archives, it made sense to keep patch-level attestation and git-level attestation
>separate.

As I see it, if git commit signatures become a requirement (maybe resulting from supply chain discussions), then using existing capabilities may be the most practical alternative. This would involve submitting signed commits in pull request via GitHub instead of emailing patches. I know this is not a desirable position for the git team, but it is currently available technology. In a pinch, that could satisfy the requirement.
-Randall

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

[Matěj Cepl]

[-- Attachment #1.1.1: Type: text/plain, Size: 1181 bytes --]

Dne 20. 10. 22 v 21:40 rsbecker@nexbridge.com napsal(a):
> As I see it, if git commit signatures become a requirement (maybe
> resulting from supply chain discussions), then using existing
> capabilities may be the most practical alternative. This would
> involve submitting signed commits in pull request via GitHub instead
> of emailing patches. I know this is not a desirable position for the
> git team, but it is currently available technology. In a pinch, that
> could satisfy the requirement.

I just think that this future is much closer than one would think. I
think that for example electronic signatures and hashes are one of
reasons why even SUSE is probably now going to ditch osc as a versioning
system and switch to git (yay! \o/). Our partners just forced us to do
so. And I really liked the true independence of git distributed development.

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Every true American would rather see this land face war than see
her flag lowered in dishonor.
  -- The Episcopal bishop of New York, William Manning, 1916

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7229 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]

On 2022-10-20 at 04:26:49, Matěj Cepl wrote:
> Hello,
> 
> did anybody even think about %subj%? Is there some effort somewhere making
> git-send-email(1) supporting transfer of signed commits, where I could join?
> I like hosting sites like sr.ht, which support git-send-email(1), but
> unfortunately using that clears my submission off its GPG signatures. I
> guess, it would be necessary to make some modifications to git-send-email(1)
> and git-am(1). Is there some effort somewhere in that direction?

There's been discussion about this in the past on the list.  I am
personally in favour of a solution which allows us to preserve the
committer and signature information in headers in the patch and apply
that to synthesize a complete commit.

I know many people who work on a patch-based workflow _don't_ want to
resynthesize the entire commit and would prefer to keep the current
approach, which I also think is fine.  However, there are situations
where end-to-end provenance is useful and so is email, and I think it's
worth supporting.

It is on my ever growing backlog of projects I'd like to implement but I
don't have any immediate plans to do so.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

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

[Matěj Cepl]

[-- Attachment #1.1.1: Type: text/plain, Size: 921 bytes --]

Dne 20. 10. 22 v 23:22 brian m. carlson napsal(a):
> I know many people who work on a patch-based workflow _don't_ want to
> resynthesize the entire commit and would prefer to keep the current
> approach, which I also think is fine.  However, there are situations
> where end-to-end provenance is useful and so is email, and I think it's
> worth supporting.
> 
> It is on my ever growing backlog of projects I'd like to implement but I
> don't have any immediate plans to do so.

Unfortunately, my Perl-foo is even weaker than my C-foo, so I am afraid
I cannot be much help here. I am sorry.

Best,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

The American Republic will endure, until politicians realize they
can bribe the people with their own money.
    -- based on a statement of Alexander Fraser Tytler

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7229 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]