Cross-signing commits

Cross-signing commits

[Soni L.]

We have a somewhat unusual use-case where we need to cross-sign commits. 
Is there any way to do this in git? As far as one can tell, attempting 
to cross-sign a commit would cause its hash to change, and creating a 
signed child commit would break fast-forward merges. So these are a no-go.

Thanks.

Re: Cross-signing commits

[brian m. carlson]

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

On 2021-03-05 at 16:47:14, Soni L. wrote:
> We have a somewhat unusual use-case where we need to cross-sign commits. Is
> there any way to do this in git? As far as one can tell, attempting to
> cross-sign a commit would cause its hash to change, and creating a signed
> child commit would break fast-forward merges. So these are a no-go.

Can you explain what you mean by "cross-signing"?  Are you proposing a
situation where two parties sign the same commit?
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

Re: Cross-signing commits

[Soni L.]

On 2021-03-05 6:44 p.m., brian m. carlson wrote:
> On 2021-03-05 at 16:47:14, Soni L. wrote:
> > We have a somewhat unusual use-case where we need to cross-sign commits. Is
> > there any way to do this in git? As far as one can tell, attempting to
> > cross-sign a commit would cause its hash to change, and creating a signed
> > child commit would break fast-forward merges. So these are a no-go.
>
> Can you explain what you mean by "cross-signing"?  Are you proposing a
> situation where two parties sign the same commit?

Yep. See, the repos enforce signing, but they can also be forks. If 
someone wants to track upstream in one of their branches they just 
can't. Would be cool if they could just say they trust the commits by 
signing the relevant commits with their own key instead - on the 
assumption that they actually reviewed said commits.

Re: Cross-signing commits

[brian m. carlson]

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

On 2021-03-05 at 21:53:14, Soni L. wrote:
> 
> 
> On 2021-03-05 6:44 p.m., brian m. carlson wrote:
> > Can you explain what you mean by "cross-signing"?  Are you proposing a
> > situation where two parties sign the same commit?
> 
> Yep. See, the repos enforce signing, but they can also be forks. If someone
> wants to track upstream in one of their branches they just can't. Would be
> cool if they could just say they trust the commits by signing the relevant
> commits with their own key instead - on the assumption that they actually
> reviewed said commits.

Git doesn't natively support having multiple signatures in a commit,
although it is of course possible to do, since OpenPGP supports it.
However, as you noted, changing the signature changes the object ID, so
if you re-sign a commit for any reason, that changes the commit ID.
There isn't any way around this at all; that's just how it works.

So you can either re-sign or have an unchanged commit ID, but not both
at the same time.

You can use additional empty signed commits or signed tags, or you can
use some sort of external system that keeps track of additional
signatures or approvals if you want.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

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

RE: Cross-signing commits

[Randall S. Becker]

On March 5, 2021 4:59 PM, brian m. carlson wrote:
> On 2021-03-05 at 21:53:14, Soni L. wrote:
> > On 2021-03-05 6:44 p.m., brian m. carlson wrote:
> > > Can you explain what you mean by "cross-signing"?  Are you proposing
> > > a situation where two parties sign the same commit?
> >
> > Yep. See, the repos enforce signing, but they can also be forks. If
> > someone wants to track upstream in one of their branches they just
> > can't. Would be cool if they could just say they trust the commits by
> > signing the relevant commits with their own key instead - on the
> > assumption that they actually reviewed said commits.
> 
> Git doesn't natively support having multiple signatures in a commit, although
> it is of course possible to do, since OpenPGP supports it.
> However, as you noted, changing the signature changes the object ID, so if
> you re-sign a commit for any reason, that changes the commit ID.
> There isn't any way around this at all; that's just how it works.
> 
> So you can either re-sign or have an unchanged commit ID, but not both at
> the same time.
> 
> You can use additional empty signed commits or signed tags, or you can use
> some sort of external system that keeps track of additional signatures or
> approvals if you want.

If your workflow requires multiple signatures on the same commit, you have options:

1. Use signed tags. So you can put multiple OpenPGP signed tags on a commit, representing each person's individual sign-off. Tags would be my preference as they show up explicitly in the git log --decorate output. Of course you will need a naming standard for this class of tags.
2. Create empty child commits with the desired commit as parent, and each person can sign their own commit - not really a great idea as history gets messy and potentially confusing.

Regards,
Randall

-- Brief whoami:
NonStop developer since approximately 211288444200000000
UNIX developer since approximately 421664400
-- In my real life, I talk too much.