Verified signatures are gone after I pressed "Rebase and merge"

Question

All commits that have been pushed to the develop branch indicate that they were verified.

To merge everything from develop to master, I decided to click a button Rebase and merge. (I didn't want to create another new commit for the master.)

Surprisingly after the merge succeeds, all the verified signatures were gone from the master.

1. What am I missing here?
2. How am I supposed to preserve the verified signature?

Roehm

Rebasing creates new commits, the old signatures are invalid and can't be reused. You have to sign the new commits, so you have to instruct rebase to apply new signatures to the commits. – Tallis

I'm not talking about interactive rebase squashing. I've already looked into the post you gave. Is this a normal behavior then? – Roehm

Rebasing constructs new commits, the hash of the parent is included in the data that is signed if I'm not mistaken, so yes, this is expected. – Tallis

While the answer of the linked 'duplicate' may be similar, the question is a different case. Voting to reopen. – Diablerie

I believe this question should be reopened. The reason is I didn't do an interactive rebase through a CLI. All I want to figure it out why the problem actually happened when I clicked the Rebase and merge button from GH. – Roehm

Can you clarify why you think that your question differs? Please do so by editing the question and providing more context – Jermayne

I've already mentioned the reason above. – Roehm

This page on GitHub Docs explains what each pull request options do under the hood. – Stag

Answer 1

When rebasing the changes are replayed on master. This causes them to be "rebased" on a new parent commit which will change the commit-id (which is partially based on the parent commit-id).

Rebasing may also require merging the changes as the commits are replayed. Even if the merge happens automatically, it may change the contents of the files. The file contents are another element that make up the commit-id.

The verification is done through a cryptographic signature of the contents and the commit-metadata. Hence, rebasing will break that signature.

To not break your signature you'll need to use a fast-forward merge (where no new merge commit is created). To achieve that you'll need to locally rebase your changes and sign them.

Or you can squash-rebase, where all your small commits are rolled up into a single new commit, which GitHub will sign on your behalf.

If verification is important to you, rebasing is generally a bad idea, fast-forward merges and merge commits will better reflect what actually happened and who had authored those changes.

Official docs:

• https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#signature-verification-for-rebase-and-merge
• https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/about-merge-methods-on-github#rebasing-and-merging-your-commits

Diablerie

Actually, the hash of the commit itself cannot be included, as that is based on the commit object, which contains the signature. Would be a chicken and the egg kind of problem. – Tallis

Your answer is well written. Thank you and it helped me to understand a general concept. – Roehm

My $0.02 1) Even if you are on top of the master, there is no conflict resolution, and your display name + email on github matches to the one on your .gitconfig: still there is one important thing happening: GitHub will alter CommitDate to match the date-time you pressed "Merge-Rebase" or "Squash-Rebase" button. This gives different commit hash and breaks signature 2) There is nothing special abou Squash-Rebase, in no way GitHub can sign a commit on you behalf, it just don't even have a private keys – Complainant

"When rebasing the changes are replayed on master. This causes them to be "rebased" on a new parent commit" -> wrong in many cases where the feature-branch is already based on the latest master (completely normal when using a rebase workflow). In this case it is the behavior of github (changing timestamps using git rebase --force-rebase) which is causing the change of commit hashes. This does not happen with other git servers like gitlab and is a really bad implementation. – Footstool

See #60597900 for details – Footstool

GitHub has a "Fast-forward merge" option in the dropdown. You don't have to select rebase. But if you do rebase, you get these issues. If your feature isn't based on the latest commit, you can't use fast-forward merges and when working with multiple developers on a single product, you'll likely have the same issues. – Diablerie

Answer 2

While the accepted answer is correct, in 2024 I have created a utility to fix this!

Go to my Bash framework at https://github.com/hopeseekr/BashScripts/

Here is a direct download link to the script itself: git-same-sig-time.

git-same-sig-time [FIRST COMMIT]

Before (after "Rebase and pull" on GitHub):

After running /code/BashScripts/git-same-sig-time 5f5de8b:

Then you'd need to do a force push:

git push -f origin trunk

Outflow

You might also be interested in git-mtime (rewrite the local modified times based on git commit timestamp) and git-commit-at-modded-time (which uses the file's modified timestamp as the git commit timestamp). – Outflow