Aman-Mittal opened a new issue, #271:
URL: https://github.com/apache/fineract-backoffice-ui/issues/271

   ## Summary
   
   Every commit on `main` today is signed. Nothing makes that true — it holds 
because the people who have contributed so far happen to have signing 
configured, and because merges made through the web UI are signed by GitHub's 
own key.
   
   The moment a contributor without signing set up opens a PR, that guarantee 
is gone, and no check will say so. That is not hypothetical: **both community 
pull requests open right now carry unsigned commits.**
   
   Measured just now:
   
   | | Signed |
   |---|---|
   | Last 15 commits on `main` | **15 / 15** verified |
   | #270 `fix(routing): redirect bare calendar and meeting paths` | `666a3a18` 
— **unsigned** |
   | #260 `fix: show domain rule errors for 403 responses` | `7a07f616` — 
**unsigned** |
   | #241, #207 | signed |
   
   There is no signing requirement in the CI workflows (`ci.yml`, `e2e.yml`, 
`codeql.yml`, `zizmor.yml`, `api-spec-sync.yml`), and nothing in the repository 
documents the expectation, so a contributor has no way to know before their 
branch is reviewed.
   
   ## Why it is easy to miss
   
   Merging through the GitHub UI with **Squash and merge** or **Create a merge 
commit** produces a *new* commit signed by GitHub's `web-flow` key, so `main` 
still reads as fully verified even when the branch behind it was not. **Rebase 
and merge** replays the original commits and preserves them unsigned. So 
today's clean history partly reflects how merges happen rather than what was 
contributed, and the protection quietly depends on maintainers never using 
rebase-merge.
   
   ## Proposal
   
   1. **A CI check that fails a pull request when any of its commits is 
unverified.** It belongs alongside the other gates in `ci.yml`, and its failure 
message should link to the setup instructions rather than just saying no.
   2. **Document the requirement** where a contributor will see it before 
pushing — a `CONTRIBUTING.md` section covering both GPG and SSH signing, and 
`git config commit.gpgsign true`.
   3. **Decide and record whether the rule is retrospective.** The two open PRs 
above would fail it. Asking a first-time contributor to re-sign a one-line fix 
after review is a poor welcome, so either the check starts from a cutoff 
commit, or maintainers agree to squash-merge those two. Whichever is chosen 
should be written down, because "it depends who merges it" is the situation 
this issue exists to end.
   
   The check should report *which* commits failed and why (`unsigned`, 
`unknown_key`, `expired_key` are the common ones from the API's 
`verification.reason`), so the fix is obvious without a round trip.
   
   ## Business Value
   
   Signing is what makes authorship in this history mean something. Without it 
a commit's author is a self-reported string — anyone able to push can attribute 
work to any name and email, and nothing downstream can tell the difference. For 
a project handling core banking, where an auditor may one day need to establish 
who wrote a particular change to a ledger or a transaction path, "the commit 
says so" is not an answer unless the commit is signed.
   
   The cost of letting this drift is asymmetric. Enforcing it now costs one CI 
job and a paragraph of documentation. Enforcing it after a hundred unsigned 
commits means either rewriting history everyone has pulled or accepting a 
permanent gap in the record.
   
   It also removes a recurring, awkward review conversation. Today the question 
surfaces after someone has done the work, as a personal request from a 
reviewer. A check turns it into something the contributor sees immediately, 
before review, with instructions attached.
   
   ## Notes
   
   Worth confirming whether the ASF has a policy here that supersedes this — 
several ASF projects require signed commits or a DCO sign-off, and this should 
match rather than invent a local rule.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to