Squash-lane repos land unsigned on main regardless of commit.gpgsign #1319

New issue

Open

opened 2026-08-27 04:28:06 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-27 04:28:06 +00:00

Owner

Found while verifying #1307, and it qualifies that issue's result rather than undoing it.

The observation

commit.gpgsign is now true on kais-macbook-pro and my branch commits verify %G? = G. Main does not:

N 54b7527c coilyco-ops[bot] | feat(shell): give ssm-get a callable form on PATH (#1314)
N 77d4735f coilyco-ops[bot] | fix(shell): stop a native session freezing its own path... (#1306)
N 57ed153f coilyco-ops[bot] | fix(aterm): name the architecture LaunchServices... (#1305)

This repo's default_merge_style is squash, so the commit that reaches main is created by Forgejo, not by the workstation. The signature on the branch commit is discarded with the branch. Workstation signing cannot reach main here no matter what commit.gpgsign is set to.

The lane decides it, and the two lanes differ:

pull-request-and-merge and pull-request land through a Forgejo-created squash commit. Unsigned. agentic-os and infrastructure are here.
merge-remote-main pushes the workstation's own commits to main, which keep their signature. agentic-os-kai is here, and its origin/main already carries a G commit.

So #1307 was correctly decided and correctly rolled out, and its benefit reaches only the direct-push lane plus branch commits under review. Saying "workstations sign every commit" without this qualification reads as though main became verifiable everywhere, and on the squash-lane repos it did not.

Why it matters

lore-stack-git-pull-verification checks commits pulled from main. On squash-lane repos that check still has nothing to verify, which is the same gap #1137 opened with, arrived at by a different route. It is highest-stakes on repos that auto-deploy on push to main.

What would close it

Signed squash commits need the Forgejo instance to sign merges it creates: [repository.signing] in app.ini, with SIGNING_KEY and MERGES in INITIAL_COMMIT, MERGES or similar. That is a running-backend change on the Forgejo deployment, so it is the Systems Administrator's to make, not the platform seat's. Filing rather than doing.

Worth deciding alongside it: whether an instance key signing every merge is the guarantee wanted, given it attests that Forgejo performed the merge rather than that Kai authored the content. The author check may remain the stronger half on these repos, in which case the answer here is to say so and stop treating the signature layer as pending.

#1137 - the purged gpg.program that started this.
#1307 - the commit.gpgsign decision this qualifies.

Found while verifying #1307, and it qualifies that issue's result rather than undoing it. ## The observation `commit.gpgsign` is now true on kais-macbook-pro and my branch commits verify `%G?` = `G`. Main does not: ``` N 54b7527c coilyco-ops[bot] | feat(shell): give ssm-get a callable form on PATH (#1314) N 77d4735f coilyco-ops[bot] | fix(shell): stop a native session freezing its own path... (#1306) N 57ed153f coilyco-ops[bot] | fix(aterm): name the architecture LaunchServices... (#1305) ``` This repo's `default_merge_style` is `squash`, so the commit that reaches `main` is created by Forgejo, not by the workstation. The signature on the branch commit is discarded with the branch. Workstation signing cannot reach `main` here no matter what `commit.gpgsign` is set to. The lane decides it, and the two lanes differ: * `pull-request-and-merge` and `pull-request` land through a Forgejo-created squash commit. Unsigned. `agentic-os` and `infrastructure` are here. * `merge-remote-main` pushes the workstation's own commits to `main`, which keep their signature. `agentic-os-kai` is here, and its `origin/main` already carries a `G` commit. So #1307 was correctly decided and correctly rolled out, and its benefit reaches only the direct-push lane plus branch commits under review. Saying "workstations sign every commit" without this qualification reads as though `main` became verifiable everywhere, and on the squash-lane repos it did not. ## Why it matters `lore-stack-git-pull-verification` checks commits pulled from `main`. On squash-lane repos that check still has nothing to verify, which is the same gap #1137 opened with, arrived at by a different route. It is highest-stakes on repos that auto-deploy on push to `main`. ## What would close it Signed squash commits need the Forgejo instance to sign merges it creates: `[repository.signing]` in `app.ini`, with `SIGNING_KEY` and `MERGES` in `INITIAL_COMMIT, MERGES` or similar. That is a running-backend change on the Forgejo deployment, so it is the Systems Administrator's to make, not the platform seat's. Filing rather than doing. Worth deciding alongside it: whether an instance key signing every merge is the guarantee wanted, given it attests that Forgejo performed the merge rather than that Kai authored the content. The author check may remain the stronger half on these repos, in which case the answer here is to say so and stop treating the signature layer as pending. ## Related * #1137 - the purged `gpg.program` that started this. * #1307 - the `commit.gpgsign` decision this qualifies.

coilyco-ops added the

role/platform

autonomy

async-consult

labels

2026-08-27 04:28:06 +00:00

coilyco-ops referenced this issue

2026-08-27 04:28:16 +00:00

Decide whether commit.gpgsign defaults to true on this fleet #1307