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?

[EduardoRT]

It's also impossible to do so with protected branches that require a pull-request + blocking force pushes for the base branch.

[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?

[diegodorado]

any updates on this?

[bfren]

As if!

[PrayagS]

3+ years and not a single concrete update 😔

[renanborgez]

this is very annoying, so much time and this is still an issue

[tylerhunt]

I've taken to manually merging PRs from the command line. When doing a git merge --ff-only <branch> and git push, GitHub will detect that the branch has been merged and close the PR. However, you do need to take care to ensure that whatever is on the branch has been pushed to GitHub before doing the merge or the PR will not be closed, and you'll be left with a mess to clean up (having to close the PR without showing it as having been merged).

[thunze]

Thanks for the pointer!

I was curious and ran some tests, and it seems that neither non-ff merges nor unpushed additional commits on the branch actually prevent GitHub from correctly detecting the merge and closing the associated PR. For example, I merged thunze/playground#5 from the command line, despite merging an additional unpushed commit and resolving a merge conflict while merging.

Where things do fall apart, i.e., PRs don't get closed, is when you don't merge all commits that have already been pushed to the remote branch associated with the PR. This can for example happen when you rebase locally before merging locally or when you squash-merge locally.

There are even more examples here: https://github.com/thunze/playground/pulls?q=.

[rubberduck203]

Just chiming in here to say that we also expected the rebase button in the UI to resign with Github's key the way it does when you perform a squash merge.

[thoran]

It's coming up to 4 years since this was opened. 👍

[njelich]

Bump, please!

[mu88]

Does anyone have a good workaround in the meantime, while the underlying problem has not been resolved? I have a branch protection rule that forces the signing of commits – I now have to manually deactivate this every time a PR is created, merge the PR, and then reactivate it. Is it possible to create any exception in the branch protection rules for PRs?

[ParadoxV5]

Push directly to prod the base is technically an option, but it’s not like one can give external contributors direct push access.

The workaround, then, is to merge by fast-forwarding: repoint the base branch to the PR’s tip using local Git, which should not recreate the contributed commits without signatures.
If the PR is not up to date, the contributor will have to rebase locally (which recreates their commits with fresh signatures) and re-(force-)push first.

Interestingly, the GitHub interface doesn’t have fast-forward-only merges; it can only require PRs to be up to date before merging.

[mu88]

Okay, but that's nothing someone can do without a Git installation - I was think about a pure web-based solution. Here's my concrete problem:

• I use Renovate's branch auto-merge strategy to keep my dependencies up to date.
• Renovate creates a new commit which triggers all necessary builds to run. These builds are also configured as status checks within the branch protection rule.
• Because I renamed a build step (which is marked as mandatory in my branch protection rule), the required build was not found by Renovate. Therefore it filed a PR. This PR shows the violated status check due to the missing build.
• I fixed the branch protection rule to use the correct build name.
• The PR is now ready to merge because all status checks are green (due to the fixed naming).
• When trying to merge the PR, I cannot merge it due to the missing Git signature of the rebased commit - so I have to disable the branch protection rule, merge the PR, and enable it again.