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

Closed
opened 2026-08-27 04:00:16 +00:00 by coilyco-ops · 2 comments
Owner

Carries settling condition 2 from #1137, which closed on the mechanism fix and would otherwise bury this.

Where it stands

#1137 landed in #1306. gpg.program on kais-macbook-pro now names /Users/kai/.local/bin/gpg-ssm, and a probe commit returns %G? = G, so signing works when asked for. commit.gpgsign is still false globally, so nothing asks for it.

That means the measurement in #1137 still holds: the last 50 commits in both coilyco-bridge/agentic-os-kai and coilyco-flight-deck/agentic-os are unsigned, and lore-stack-git-pull-verification is running on its author check alone. The signature layer is now available rather than inert, and still switched off.

The decision

Whether commit.gpgsign should be true by default on this fleet. It is Kai's call and was not assumed by the fix.

What flipping it costs, so the call is priced rather than guessed:

  • Every commit invokes gpg-ssm, which gates on aws sts get-caller-identity before signing. A host with expired SSO credentials stops being able to commit until aws sso login, rather than committing unsigned.
  • First sign in a gpg-agent session reaches SSM twice (secret key when absent, then passphrase). Later signs in the same session reuse the cached unlocked key, so the SSM cost is per agent lifetime rather than per commit.
  • CI and container seats commit as coilyco-ops[bot] through docker/dev-base/git-identity.sh, which sets user.name and user.email and no signing key. Defaulting commit.gpgsign true fleet-wide needs an answer for those seats: sign as the shared key, or leave them explicitly unsigned.

What settles it

A stated answer, and if it is yes, the rollout in infrastructure/ansible plus a decision for the bot seats. Convergence stays with the ansible shell role per the authoring-versus-rollout contract, so nothing about the flip lands in this repo except possibly a doc line.

Carries settling condition 2 from #1137, which closed on the mechanism fix and would otherwise bury this. ## Where it stands #1137 landed in #1306. `gpg.program` on kais-macbook-pro now names `/Users/kai/.local/bin/gpg-ssm`, and a probe commit returns `%G?` = `G`, so signing works when asked for. `commit.gpgsign` is still `false` globally, so nothing asks for it. That means the measurement in #1137 still holds: the last 50 commits in both `coilyco-bridge/agentic-os-kai` and `coilyco-flight-deck/agentic-os` are unsigned, and `lore-stack-git-pull-verification` is running on its author check alone. The signature layer is now available rather than inert, and still switched off. ## The decision Whether `commit.gpgsign` should be `true` by default on this fleet. It is Kai's call and was not assumed by the fix. What flipping it costs, so the call is priced rather than guessed: * Every commit invokes `gpg-ssm`, which gates on `aws sts get-caller-identity` before signing. A host with expired SSO credentials stops being able to commit until `aws sso login`, rather than committing unsigned. * First sign in a gpg-agent session reaches SSM twice (secret key when absent, then passphrase). Later signs in the same session reuse the cached unlocked key, so the SSM cost is per agent lifetime rather than per commit. * CI and container seats commit as `coilyco-ops[bot]` through `docker/dev-base/git-identity.sh`, which sets `user.name` and `user.email` and no signing key. Defaulting `commit.gpgsign` true fleet-wide needs an answer for those seats: sign as the shared key, or leave them explicitly unsigned. ## What settles it A stated answer, and if it is yes, the rollout in infrastructure/ansible plus a decision for the bot seats. Convergence stays with the ansible shell role per the authoring-versus-rollout contract, so nothing about the flip lands in this repo except possibly a doc line.
Author
Owner

Answered by Kai: yes on workstations, bot seats left unsigned. Signing is worth having where merges originate, and not worth a hard dependency on SSM reachability for an unattended host.

Live on kais-macbook-pro. commit.gpgsign is true, and both commits in #1314 verify %G? = G with the shared keyid. That is the first signed commit in this repo's recent history, so the signature layer of lore-stack-git-pull-verification is now producing something to check rather than merely being available.

Fleet rollout landed in coilyco-flight-deck/infrastructure#960. The shell role now owns both settings via community.general.git_config:

  • gpg.program at ~/.local/bin/gpg-ssm, spelled from ansible_facts['env'].HOME so convergence names the durable host home. That is what stops the role reproducing #1137 the way a hand-run git config --global from a session does.
  • commit.gpgsign true off hostclass_server, so workstations sign and the server class does not.

Container and CI seats need no change: they commit through docker/dev-base/git-identity.sh, which backfills user.name and user.email from the Ward transport seam and no signing key, and they never read a workstation's ~/.gitconfig. They stay unsigned by absence rather than by an added setting.

Reasoning and the per-host verification are in infrastructure docs/ansible-guardrails.md.

One step is not done and should not be read as done. just ansible-sync check tags=shell refuses to run inside a native session shadow, naming the same hazard as #1137, so the converge has not been exercised. Running just ansible-sync tags=shell from a terminal outside an agent session is what puts the other workstations in the target state. Per-host check afterward: git log -1 --format='%G? %GK' on a fresh commit returns G plus the shared keyid.

Closing on the decision and its rollout. The converge run is ordinary fleet operation rather than open work.

Answered by Kai: **yes on workstations, bot seats left unsigned.** Signing is worth having where merges originate, and not worth a hard dependency on SSM reachability for an unattended host. **Live on kais-macbook-pro.** `commit.gpgsign` is `true`, and both commits in #1314 verify `%G?` = `G` with the shared keyid. That is the first signed commit in this repo's recent history, so the signature layer of `lore-stack-git-pull-verification` is now producing something to check rather than merely being available. **Fleet rollout landed** in `coilyco-flight-deck/infrastructure#960`. The `shell` role now owns both settings via `community.general.git_config`: * `gpg.program` at `~/.local/bin/gpg-ssm`, spelled from `ansible_facts['env'].HOME` so convergence names the durable host home. That is what stops the role reproducing #1137 the way a hand-run `git config --global` from a session does. * `commit.gpgsign` true off `hostclass_server`, so workstations sign and the server class does not. Container and CI seats need no change: they commit through `docker/dev-base/git-identity.sh`, which backfills `user.name` and `user.email` from the Ward transport seam and no signing key, and they never read a workstation's `~/.gitconfig`. They stay unsigned by absence rather than by an added setting. Reasoning and the per-host verification are in `infrastructure` `docs/ansible-guardrails.md`. **One step is not done and should not be read as done.** `just ansible-sync check tags=shell` refuses to run inside a native session shadow, naming the same hazard as #1137, so the converge has not been exercised. Running `just ansible-sync tags=shell` from a terminal outside an agent session is what puts the other workstations in the target state. Per-host check afterward: `git log -1 --format='%G? %GK'` on a fresh commit returns `G` plus the shared keyid. Closing on the decision and its rollout. The converge run is ordinary fleet operation rather than open work.
Author
Owner

Correcting the previous comment. I checked main after posting it, and the reach of this is narrower than I said.

This repo squash-merges, so the commit landing on main is created by Forgejo and the branch commit's signature goes with the branch. main here is still N on every commit including the two from this work. "The signature layer is now producing something to check" is true of branch commits and of direct-push repos like agentic-os-kai, and false of main on agentic-os and infrastructure.

The decision and its rollout stand as landed. What changes is what to expect from it: workstation signing covers branch commits under review and the merge-remote-main lane, not main on squash-lane repos. Closing that gap needs Forgejo instance-side merge signing, which is a running-backend change and the Systems Administrator's to make. Filed as #1319 with the config surface and the question of whether an instance signature is the guarantee worth having.

This issue stays closed. #1319 carries the remainder.

Correcting the previous comment. I checked `main` after posting it, and the reach of this is narrower than I said. This repo squash-merges, so the commit landing on `main` is created by Forgejo and the branch commit's signature goes with the branch. `main` here is still `N` on every commit including the two from this work. "The signature layer is now producing something to check" is true of branch commits and of direct-push repos like `agentic-os-kai`, and false of `main` on `agentic-os` and `infrastructure`. The decision and its rollout stand as landed. What changes is what to expect from it: workstation signing covers branch commits under review and the `merge-remote-main` lane, not `main` on squash-lane repos. Closing that gap needs Forgejo instance-side merge signing, which is a running-backend change and the Systems Administrator's to make. Filed as #1319 with the config surface and the question of whether an instance signature is the guarantee worth having. This issue stays closed. #1319 carries the remainder.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-flight-deck/agentic-os#1307
No description provided.