Adam - I think this discussion is good but perhaps to get to a consensus, we should take a vote to switch to the traditional merge without ff.
I’m convinced we went off the correct path and now need to return to it. It’s potentially more “work” but it will become routine and tooling is there. James On Thu, Mar 5, 2026 at 8:53 PM KRISHNA MEWARA <[email protected]> wrote: > Hi Adam, your analysis is spo on. The GitHub UI rewrites the commit during > the squash/rebase, which naturally strips the original signature. > > I strongly vote for your Second Idea (traditional merge commits without > fast-forwarding). > > Since we already have the verify-signed-commits.sh script running in our > CI (which I recently set up) to validate signatures on the PR branch, the > infrastructure is completely in place. The only gap right now is that the > final GitHub merge operation destroys those validated signatures. > > To your point about examining a simplified history despite having more > commits: we can just rely on git log --first-parent develop. That filters > out the noise and gives us the exact clean view of PR integrations we're > used to, while preserving the granular, signed developer intent > underneath. > > This is exactly how the Linux Kernel and Kubernetes handle it now > (especially K8s post-xz attack). The only real shift in our workflow would > be asking contributors to squash their "wip" or "fix typo" commits locally > before we merge. > > If the team is on board with this route, the flip over is pretty > straightforward: > > 1. > > Uncheck "Squash and merge" and "Rebase and merge" in the repo > settings, leaving only "Allow merge commits". > 2. > > Enable "Require signed commits" on the develop branch protection rules. > 3. > > Update the merge strategy in CONTRIBUTING.md. > > *(Side note: Longer term, keyless signing via Sigstore/Gitsign is worth > keeping on our radar. K8s is already evaluating it, and it could eventually > save everyone the headache of managing GPG keys).* > > Curious to hear what others think about making the switch. > > Best Regards, > > Krishna Mewara > > On Fri, 6 Mar 2026 at 02:07, Adam Monsen <[email protected]> wrote: > >> Per Ádám Sághy we're seeing proper signed commits for PRs while commits >> are under review, but the eventual merged commit of the PR is unsigned. >> >> I think this is due to the way we get commits for PRs back into the main >> integration branch (develop) using the github web UI. We (again, via the >> gh web ui -- this is significant) squash commits on the PR branch into one >> commit, rebase on tip of develop, and finally fast-forward merge develop >> to that new commit. The Fineract committer's contact info is in the >> committer field of the commit, then gh does all that sqash/rebase/merge >> dance and preserves that committer field, but github doesn't have that >> person's private key, hence, can't sign the commit. >> >> Agree/disagree? >> >> I have a couple ideas. First idea: >> >> It should work to continue to use the gh web ui for merging PRs but avoid >> the rebase step before merging, so the squashed commit is traditionally >> merged by github. The PR commit and the merge commit remain signed with >> valid signatures. As long as the author/dev/committer does the squashing >> locally, this should work. There is one catch that, by avoiding the rebase >> step, instead of a "clean" git history you get one little merge commit >> triangle after each PR is merged. Kinda annoying. >> >> Second idea: >> >> My personal preference--and I get this is a more radical change--is to >> simply use traditional branches and merges for PRs. No squashing into a >> single commit, no ff merge at the end. Rebasing on the tip of develop is OK >> as long as it is done carefully. I prefer this always since it preserves >> more history and more developer intent. When I'm looking at commit history, >> I want to be able to know exactly what happened, when, by whom, and why. I >> want to see branch start & end points, when changes were made and unmade. >> Yes it means more commits. Thankfully Git is built to handle many, many >> commits. It has excellent filtering to, for example, examine simplified >> history. >> >> Thoughts? >> >> Anyone else have ideas on how we can preserve verifiable commit >> signatures? >> >> On Thu, Feb 5, 2026 at 7:44 PM Adam Monsen <[email protected]> wrote: >> >>> There's a new ci action for PRs to check that new commits are signed. >>> >>> All committers already have PGP/GPG keys, so just make sure you're also >>> signing commits. You can add this to your ~/.gitconfig (or equivalent) >>> to do it automatically: >>> >>> [commit] >>> gpgSign = true >>> >>> Upload your public key to github <https://github.com/settings/keys> to >>> make the verified badges green. >>> >>> More info: FINERACT-2177 >>> <https://issues.apache.org/jira/browse/FINERACT-2177>, PR #5431 >>> <https://github.com/apache/fineract/pull/5431>. >>> >>> Hints: 1) try it locally before pushing. 2) have git run it for you: >>> Create .git/hooks/pre-push with: >>> >>> #!/bin/sh >>> scripts/verify-signed-commits.sh --strict >>> >>> Be sure to make that script executable. >>> >>> -- >>> Adam Monsen >>> Software Engineer » Mifos Initiative >>> Release Manager » Apache Fineract >>> Author » Steadfast Self-Hosting >>> PGP key » 0xA9A14F22F57DA182 >>> >>>
