Re: signed commits

[Adam Monsen <am...@mifos.org>]

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 <am...@mifos.org> 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
>
>

Re: signed commits

[Adam Monsen <me...@apache.org>]

Yes, but please see my message below: I would like to wait 72hrs in case 
people are able to help me perfect FSIP-7.

On 3/10/26 10:47, Ádám Sághy wrote:
> Shall we do a vote about this?
>
>> On Mar 10, 2026, at 6:36 PM, Adam Monsen <me...@apache.org> wrote:
>>
>> Agreed! Thank you Krishna and James.
>>
>> I wrote this up. Please see FSIP-7: traditional merge strategy 
>> <https://cwiki.apache.org/confluence/display/FINERACT/FSIP-7%3A+traditional+merge+strategy>.
>>
>> Feedback welcome! Please comment on or edit the wiki page directly. 
>> I'll let that proposal marinate for at least 72hrs before starting a 
>> vote.
>>
>> Ádám Sághy: I put you down as "reviewer" because we discussed it 1:1, 
>> but I don't mean to force you into that role. Your call.
>>
>

Re: signed commits

[Ádám Sághy <ad...@gmail.com>]

Shall we do a vote about this?

> On Mar 10, 2026, at 6:36 PM, Adam Monsen <me...@apache.org> wrote:
> 
> Agreed! Thank you Krishna and James.
> 
> I wrote this up. Please see FSIP-7: traditional merge strategy <https://cwiki.apache.org/confluence/display/FINERACT/FSIP-7%3A+traditional+merge+strategy>.
> 
> Feedback welcome! Please comment on or edit the wiki page directly. I'll let that proposal marinate for at least 72hrs before starting a vote.
> 
> Ádám Sághy: I put you down as "reviewer" because we discussed it 1:1, but I don't mean to force you into that role. Your call.
> 

Re: signed commits

[Adam Monsen <me...@apache.org>]

Agreed! Thank you Krishna and James.

I wrote this up. Please see FSIP-7: traditional merge strategy 
<https://cwiki.apache.org/confluence/display/FINERACT/FSIP-7%3A+traditional+merge+strategy>.

Feedback welcome! Please comment on or edit the wiki page directly. I'll 
let that proposal marinate for at least 72hrs before starting a vote.

Ádám Sághy: I put you down as "reviewer" because we discussed it 1:1, 
but I don't mean to force you into that role. Your call.

Re: signed commits

[James Dailey <jd...@apache.org>]

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 <kr...@gmail.com>
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 <am...@mifos.org> 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 <am...@mifos.org> 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
>>>
>>>

Re: signed commits

[KRISHNA MEWARA <kr...@gmail.com>]

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 <am...@mifos.org> 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 <am...@mifos.org> 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
>>
>>