Hub: Persist GPG Verified Signed Commit On "Squash and Merge" and / or "Rebase and merge" In PRs

[Sayvai]

On GitHub Enterprise (GHE) v2.7.x, when I make a Pull Request (PR) with a single commit on a feature branch that is signed with a verified GPG signature, and eventually merge this in via the click action on the button labelled _Confirm squash and merge_, the commit is no longer signed with a verified GPG signature. So my question is, _could GPG signed verified commit(s) status(es) from feature branches please be persisted into the branch it is merging into in the PR squash and merge process? Or even when using the Rebase and merge option?_ At least especially if there is _only one new commit, which is GPG signed_ from a feature branch.

[mislav]

Hello! You seem to have a question about the functionality of GitHub itself. This project is called "hub" and is _related_ to GitHub, but only as a GitHub API client on the command-line. The "Confirm squash and merge" functionality is not related to this project at all.

Could you write to [email protected] instead? Thanks!

[Sayvai]

Got this reply back from GitHub Support on 14th September 2016:

_We are looking into ways to sign merge and squash-merge commits, as well as commits made through the web interface. The challenge is that we do not want you to upload your private GPG key to GitHub Enterprise, which is required for signing. Your private GPG key should remain secured on your workstation._

_Most likely, the solution will be for these types of commits to be signed by a GitHub GPG key specific to your GitHub Enterprise server. I do not, however, know when or if this feature will be available in GitHub Enterprise._

I also noticed this recent announcement from GitHub themselves on 26th September 2016 surrounding a new merge option available in Pull Requests (PR) on GitHub.com only; Rebase and merge, to which i believe may resolve this problem. If it does, then i hope the feature will also be released to GitHub Enterprise (GHE) soon!

[HBelusca]

Problem still happens even using "Rebase & Merge".

[nburroni]

Are there any updates on this matter? I am having the same issue

[Sayvai]

There's been no updates on this matter 😞

I have re-sent an email to [email protected] to chase up on this. I'll post response here, if / when i get a response back.

For the rest feel free to do the same, and even link to this issue, so that more awareness is gained, and eventually potentially prioritised.

[Sayvai]

Just got a response from a GitHub representative:

Keeping the verified status when you squash and merge commits from a Pull Request has been available on GitHub.com for a while now. This feature hasn't yet made it to GitHub Enterprise due to some underlying architecture that differs between the two platforms.

We had an issue discussing this feature which I'm going to reopen and see if we can get it across the line and into GitHub Enterprise. I can't promise if or when this may make it to GitHub Enterprise however.

So, the feature ticket has been reopened internally, and hopefully they'll manage to apply the feature to their _GitHub Enterprise_ product like they've done with _GitHub.com_ 🤞

I'll chase up again in like 2 / 3 months time.

[crudobaker]

Hello! Are there news from this issue?

[Sayvai]

@lisito Thanks for the reminder ^^

So i've just chased up, and got the following response from GitHub Support:

We are still tracking this as an open issue, and it is being discussed by the relevant teams. However, I am unable to provide any timelines for when we may see this feature be added to GitHub Enterprise. Please feel free to reach out for an update at any point.

So no real progress yet it seems. Patience for now it will have to be.

[crudobaker]

Thanks Sayvai :+1:

We will wait for news.

[5chdn]

Keeping the verified status when you squash and merge commits from a Pull Request has been available on GitHub.com for a while now.

However, this only works if the person who hits the squash button is the same as the user who signed the commits in the pull request. Why is that?

If I have a PR, that has full signed commits by developer A, and developer B merges this, it will generate an unsigned merge commit. That's very unfortunate.

[jakob223]

@Sayvai any update on this?

[medikoo]

Keeping the verified status when you squash and merge commits from a Pull Request has been available on GitHub.com for a while now.

Unfortunately it's not the case for "Rebase and merge"

[Sayvai]

So i've chased up on the ability with persisting the GPG signed commits via the _Rebase and merge_ action, and this is the latest response from _GitHub Support_.

I'll pass your request onto the team to consider. Commit signing wasn't implemented for Rebase merge I'm afraid.

I can't promise if or when it will be implemented, but your suggestion is definitely in the right hands!

Lets hope this is given some serious consideration, and eventually implemented 🤞

[gt-novelt]

@Sayvai any news on this ?

Unfortunately the _rebase and merge_ still don't preserve signature.

[bluexbyte]

we are also unable to just regular merge verified gpg commits on github enterprise server 2018.9 when it is enforced via branch protection rules... possibly related but unsure. have openned ticket with github support and will update here.

Also curious as to if there is a different open issue for tracking this work publically?

---

GITHUB DROP ICE

[abbec]

We also run in to this, quite annoying so we have reverted back to merging manually and not using the merge button in the UI. It seems like "rebase and merge" in combination with the requirement that the branch has to be up to date should remove the requirement to even do a rebase and just do a merge --ff-only, thus preserving the signing?

[Sayvai]

So i've chased up again with _Github Support_, and got some bad news.. 😞

Unfortunately I do not have the best news for you.

I've spoken with our engineering team responsible for the commit signing feature. It's not currently expected that rebased commits from a rebase and merge will be signed.

[errordeveloper]

In understand that in principle it is the right thing to do, since GitHub is shouldn't be signing any commits on user's behalf. Albeit, I think they should at least allow rebase+merge with signatures dropped from resulting commits.

[medikoo]

In understand that in principle it is the right thing to do, since GitHub is shouldn't be signing any commits on user's behalf. Albeit, I think they should at least allow rebase+merge with signatures dropped from resulting commits.

If they can sign squash commits I do not understand why rebase commit cannot be signed

[errordeveloper]

If they can sign squash commits I do not understand why rebase commit cannot be signed

@medikoo good point! I've checked it, and they actually use their own key to sign squash commits. I think this is definitely a huge issue with what's meant to be one of the flagship security features. It looks like they just stop short of signing each commit on rebase, which is odd because if I rebase someone's commits locally, those get signed with my key automatically, so it's not like a non-trivial kind of thing to implement.

[renannprado]

Gitlab implementation makes totally sense.

Just offer a button which merges the branch as is - it's not true that every time you want to merge a branch you want to squash all your commits.