Rebased commits by the web interface aren't signed

[BasixKOR]

Hi!

First of all, I'm more than happy to rebase my branch on GitHub without switching, pulling and all the jazz. However, when I rebase my branch on the PR by clicking 'Update with rebase', my signed commits become unsigned, resulting in an 'Unverified' badge if the user is using the vigilant mode.

IIRC GitHub signs the commit that has been created on the website by GitHub's key, and I was wondering if we could do the same for rebasing too.

[BasixKOR]

This seemingly also applies to the "Merge with Rebase" feature too.

[ebndev]

Hi @ashrafkhanak1, thanks for being a part of the GitHub Community!

Please note: we’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team.  You can read our updated Code of Conduct and the announcement for more details. Thank you for helping us maintain an authentic and beneficial space for everyone.

[dvakatsiienko]

This actually causes a lot of conflicts each time after local rebase once you pull main that is contains «rewritten without a sign» commits by Github, and rebase it onto existing branch that contains those commits in signed form. Thus, making Github Rebase feature pretty unusable which is bad.

[export-mike]

any updates on allowing github to sign your commits on a rebase?

[dvakatsiienko]

doesn't seem so :(

[devnoname120]

This will probably get deprecated as an “outdated issue” like all those long-running bugs below. 😆😆
github/roadmap#1014

@ankneis quickly locked the discussion of this announcement, probably in an effort to cens… uh I mean in order to listen more to their users, embody transparency, and give customers the chance to contribute their experience to help influence the roadmap.

[kshehadeh]

For what it's worth, this also seems to be an issue if you're using the API to rebase a PR which contains only signed commits.

[oliverbevan]

any update on this?

[mrsimonemms]

FWIW, it seems like a recent change. I've used this workflow for AGES and it's only in the past week or two where I've seen unverified changes after merging the PR via the website

[Murali-Shl]

Hi,
I am getting similar issue of getting the error 'branch is out-of-date with the base branch' and when I click the Rebase button in the UI, it is re-running the workflows (push commit and create PR actions)..

Or I can click on bypass the checks to merge into master.

[REBELinBLUE]

Also seems to happen when you revert a PR, I am sure it used to work in the past

[alexandrmazur96]

Is any fix existing for this?

[danielnorberg]

Would love to see this fixed. It's pretty jarring to see a lot of Unverified commits in PRs, especially when not knowing it's due to the web UI rebase.

[zliang-akamai]

Still can observe the issue. Can you guys try to fix it?

[jorgediaz-lr]

I have also detected this issue.

[magneland]

Same.
Until the web interface is fixed, my workaround is to re-sign the commits locally:

gpg --list-secret-keys --keyid-format=long
git config --global user.signingkey <your key>
git rebase --exec 'git commit --amend --no-edit -n -S' -i <SHA before the one to fix>

[learosema]

I've put an alias for the rebase in my .gitconfig :)

[alias]
    resign = "!f() { git rebase --exec 'git commit --amend --no-edit -n -S' -i \"$1\"; }; f"

unintended pun

[i-nadia]

For those who already rebased through the web interface :

git pull
git commit --amend --no-edit --signoff
git push --force-with-lease

[dannyrife]

Hit this again today. Used the script above to fix. Any update?

[microhobby]

Yeah, still broken. Some updated? It's annoying to have to do it manually when using GitHub.

[maxim]

Yeah, the pull request merge buttons no longer seem to sign my commits. It used to work a few months ago, and now it doesn't. I'm using an SSH Signing Key.

[azizur]

Any update on this? I just spotted the same issue.

[pektezol]

@magneland 's command works well, but I really don't want to force-push everytime I have to rebase. Why would the commits be unverified if it's on Github's own page and pull request, AND the commits are already signed..

Can we get some update on this?

[karrakoliko]

Any update on this?

[tiriana]

Does anyone have a workaround for this? Right now I resign commits locally and push --force-with-lease them

[gorbak25]

+1

[ForsakenRei]

I hit this issue as well. And based on Github doc, since Github has no access to the private key then it cannot sign the commits, you can only merge it locally and then push as a workaround.

But as above I remembered it worked before, now I'm wondering how it works before...

[bklebe]

Correct, commits made via the web UI are signed with GitHub's key. This is what I would assume they'd do for rebases in the web UI, but I guess maybe they feel uncomfortable signing commits that might be made by multiple users with the same key?

[bfren]

(or even users that have made unsigned commits I guess?)

[ForsakenRei]

I cannot say for others but I sign all my own commits.

[bfren]

I feel on repos where multiple people contribute, it would be pretty easy to say 'if all the commits in this PR are signed, then sign the merge commit by the user doing the merge'.

If all the commits in a PR were not signed however that wouldn't be possible.

[matfax]

I think the reason for this change is that GitHub now also discards the signatures of rebase merges. In theory, this doesn't require any change to the commit, so the signature could remain unchanged. But for some reason, GitHub adds the merging party into the author list - without review, without adopted code suggestions, just for clicking the (auto) merge button. This is nonsensical. The commit only has to change with squashes, hence requiring a new signature. I'm also not sure what happened to the "partially verified" feature. It just shows up as unverified now. GitHub could solve this by re-signing the commit with a key to which you grant access for web signing. Perhaps, also add passkey-encryption or access. Or use the smartcard feature that most browsers have and let users store their keys on their personal hardware.

[jramosf]

I've raised a support ticket to see if we can get an official response from GitHub on this one.

[jramosf]

I am not sure if I can paste the verbatim contents of the response from the support engineer here, but basically I got response and they have open issues on Engineering but no specific commitment at the moment.

Pasting my own response as I've already closed the ticket.

I'll keep an eye on this thread and in GitHub changelog in case it gets implemented in the future.

[richard-stafflink]

@jramosf did you get around to logging a ticket? If so, any updates?

[bhatiashivam]

Is anyone aware of any official response from Github? Right now I resign commits locally and push with --force-with-lease.

[bfren]

Only what @jramosf posted a few days ago - obviously they're aware of it but have no plans to do anything about it.

[dvins]

Maddening, open two years. Instead of doing simple updates in UI from a phone or tablet have to lug around my laptop and fire up full Git to be able to merge a stack of PRs.

[tiriana]

We disabled rebase because of this.
Atlassian has tickets open since 2014. 2 years is like a warmup.

[dvins]

@ebndev Is someone on the GitHub team responsible for this issue? Its nigh on two and a half years and frankly its an infosec security and provenance matter.

[dvins]

@ebndev Can we please get a little attention on this from you even or another GitHub community manager, if only to point us in the direction of whom else we should be trying to speak with? As stated previously, this is an infosec security and provenance matter. This thread, with more than 300 bumps and thumbs ups, has now been open without feedback from GitHub for more than two and a half years.

[ebndev]

Hi @dvins, I've brought this to the attention of the Community Manager of this category so they can assess the feedback and forward it to the proper GitHub team.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

We appreciate you bringing attention to an older however, for future incidents-- please know that we do actively check the "Product Feedback" label and follow the processes mentioned above. Community members can upvote, comment, and react with discussions that resonate with them to voice their support on feature requests.

While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thanks for understanding! ⭐

[dvins]

Thank you @ebndev, much appreciated. Do be aware that there is no tag on this that indicates this is an infosec and security related issue though. As others have indicated, this bug allows others to work around protection rules and results in undue provenance when performing merges.

[matfax]

If you're merging a PR as bypass listee, this even ignores the "Require signed commits" protection rule without giving notice.

[BoscoDomingo]

October 2024, this is still an issue. 2 years and almost 8 months...

[ferrata]

Hey GitHub team! I just saw an announcement that Persistent commit signature verification now in public preview. Does it mean that this issue is going to be addressed?

[Kingg22]

I still have this problem, only the commits with push to master have verified

[devnoname120]

Not even gh pr merge 123 works. This command generates the merge/rebased/squash commit from GitHub's side rather than locally, so it has the same problems as with the web interface.

[AndreasPresthammer]

My team has enabled required signed commits for our main branch. We've hit this stumbling block where we no longer can rebase PRs into the main branch due to this exact issue. We then had to fall back to using squash commits or merge commits into the main branch.

I find it very odd that github has no problem signing squash commits and merge commits with their own key, but doesn't support re-signing rebase commits into main. Having a rule in the github rebase logic to only allow resigning of verified commits sounds fairly trivial to do. This would allow us to start using the rebase-to-main flow again and still retain the requirement for signed commits in main.

Alternatively github could avoid re-creating the commits, but instead allow for fast forward merge to main which would retain the PRs unchanged, already signed, commits to go into main.

The situation as it stand reduces the quality of our main branch, since in my teams workflow we often want to retain the commits from the PR into main. Sadly we cannot do this today with signed commits requirement in main with this current limitation.

We can retain history using merge commits, but this causes a noisy main history which would prefer not to have.

[vRune4]

Alternatively github could avoid re-creating the commits, but instead allow for fast forward merge to main which would retain the PRs unchanged, already signed, commits to go into main.

For me that would be the best solution. (I don't see why this isn't the default to begin with)

[YoshiRulz]

Something like #6414?