git-imerge rebase does not sign commits despite `gpgsign = true` in `.git/config`

[mgudemann]

Thanks for git-imerge which is really great to reduce the pain of merge conflicts.

For some repos I have the requirement that each commit must be signed. Unfortunately using git imerge rebase $BRANCH does not seem to sign the rebased commits despite the gpgsign = true setting in the .git/config of the repository, git rebase $BRANCH does.

How can I resolve this?

[mhagger]

I don't use gpgsign myself, so I'm not really familiar with the details of how it works. Let me braindump a few bits of information that might be related:

• While it is doing the incremental merge, git-imerge mostly uses git merge and git commit to create new commits. Are those commits getting signed as you would expect? (My guess is "yes".)

• When the merge is done, git-imerge finish often creates new commit objects using GitRepository.reparent, which takes an existing commit (including its tree) and creates a new tree with different parents using git hash-object. I highly suspect that this step doesn't cause the resulting commit to be signed.

If that's all correct, then it seems to me that we need either a replacement for git hash-object in GitRepository.reparent that does signing correctly, or we need to sign the commit afterwards using something like git commit --amend --no-edit -n -S.

Do you have any insight here?

[mgudemann]

@mhagger

While it is doing the incremental merge, git-imerge mostly uses git merge and git commit to create new commits. Are those commits getting signed as you would expect? (My guess is "yes".)

exactly, that happens, e.g.,

commit 86a30130a55990b3b8ecb835c7a769075dbe66ef (HEAD, refs/imerge/haskell/use_non-integer_calculations/auto/29-1)
gpg: Signature made Mon 04 Mar 2019 04:34:17 PM CET
gpg:                using RSA key 1FF01776D52E0D1940F5E137734ECFFF51BEA8B5
gpg: Good signature from "Matthias Güdemann <[email protected]>" [ultimate]
Merge: 610c3b5 65dac66
Author: Matthias Güdemann <[email protected]>
Date:   Mon Mar 4 16:34:17 2019 +0100

    imerge 'haskell/use_non-integer_calculations': automatic merge 29-1

When the merge is done, git-imerge finish often creates new commit objects using GitRepository.reparent, which takes an existing commit (including its tree) and creates a new tree with different parents using git hash-object. I highly suspect that this step doesn't cause the resulting commit to be signed.

exactly that happens, after the interactive rebase I get

commit 00460b8c48335532d26154c57e792591eb11b534 (HEAD -> haskell/use_non-integer_calculations)
Author: Matthias Güdemann <[email protected]>
Date:   Thu Feb 7 12:00:04 2019 +0100

    Add `rounding` column to non-integral overview

which isn't signed

Using git commit --amend --no-edit -n -S is the approach I currently use. Most rebased branches do not have many commits, so this is feasible without problems. Still, it would be nice to get the commits signed directly in the finish step.

[kj4ezj]

I don't use gpgsign myself, so I'm not really familiar with the details of how it works.

You should consider this. It makes it difficult for an attacker to push fraudulent commits to your project without being noticed. I use a different GPG key for each physical computer and user account, so if an attacker got access to my GPG keys then I know which computer was compromised.

The reason I am commenting at all is because many serious project and enterprises using GitHub now require GPG signatures on all commits in their repositories. Please consider making sure all commits generated by git-imerge are signed.