ntfy publisher token onto GCP custody: consolidate #11679 into one custody roster

[gunbai-bot]

Roadmap node ntfy-publisher-token-onto-gcp-custody. This merges the ntfy publisher token into the custody module from #11679 rather than adding a sibling module (DESIGN §3).

What changed

• One custody authority, renamed. gunbc.microvm_controller_app_key_converge → gunbc.host_credential_custody_converge, moved to dag/gunbc/fleet/. The old path is deleted.
• One fleet-converge mode. It is host_credential_custody_converge, and the new credential dispatch input is a choice over the closed roster host_custody_credential_roster (controller_app_key, approval_ntfy_publisher_token). An unrostered word refuses with a typed error (HostCustodyCredentialUnrostered). There is no free-text path to a SecretRef.
• The controller key is the first row. Its old root:root 0400 and 0700 directory constants are now that row's fields.
• Each row carries a SecretRef, a path, a host scope, the file's owner/group and mode arm, and the directory's owner/group and mode arm. The ntfy row is root:gunbc-ntfy 0640 in a root:gunbc-ntfy 0750 directory, srv1 only. A witness holds that directory equal to approval_ntfy_converge NtfyConfigDirectory, so the two converges cannot fight over it.
• Both find legs come from the arm, never from a caller octal. Files: exact 0400/0640 with forbidden bits /077//037. Directories: exact 0700/0750 with forbidden bits /077//027. The owner leg takes -user/-group from the row. A chown leg applies the row's owner and group after the typed write, because the write lands root:root.
• The directory check was fixed in the row model, not relaxed. The old check refused any group bit on the directory. Now the directory's allowed bits come from the row's directory arm.
• The HumanIntervention is deleted. What stays human is the mint (approval_ntfy_publisher_token_mint_intervention): creating the ntfy user and adding its token to Secret Manager. That is a different fact from delivery. The token's SecretRef (approval_ntfy_publisher_token_secret_ref, latest) lives in gunbc.auth.approval_ntfy_deployment and is a new row in gunbc.auth.fleet_secret_accessor_roster.
• Ported fixes from main (landed on the old module after this branch started):
  • The three source findings raised against #11679 after it merged (ordering, runner-width coupling, false absence) #11902: the host subject resolves from the runner spec, not the slot width; staging cleanup needs a sealed StagingCleanupAuthorization; ancestors are observed before install -d runs.
  • Repair the test -e absence probe in runner_host_file_converge (metadata failure read as absent) #11845: classify_host_file_presence is deleted on main, so main's copy of the old module no longer resolves. The content probe here now reads presence from an elevated parent listing that succeeded, never from test -e.

Controls (on the real admission path, custody_row_placement, which the CI entry runs before any Secret Manager read)

• Red: the real ntfy row with only its directory arm narrowed to 0700 → CustodyGroupCannotTraverse. The refusal names the path, directory, group and both modes, and nothing widens. A second red: a directory owned by another group → CustodyDirectoryGroupDiffers.
• Positive: the same ntfy row, unchanged, places in /etc/gunbc-ntfy, and every rostered row places.
• Witness results: test.claim.host_credential_custody_converge_witness 37/37. Also re-run: gcp_secret_access 36/36, approval_ntfy_deployment 17/17, host_convergence_census 12/12, authorization_pattern_selection 12/12, workflow_dispatch_input 20/20, host_convergence_protocol 23/23, workflow_capability_closure 8/8. The last seven ran before the merge with main.

What this does NOT establish (must not be lost)

A find-metadata readback shows which principals hold permission bits. It does not show that a non-writer cannot open the file. Showing that needs a leg that runs as another user and is refused. gunbc.rung_drop approval_store_single_writer_by_agreement names that stronger observation as its restoration trigger, and it lists a permission-bits readback among the things that do not retire it. So this work is necessary but not sufficient for that trigger. The same caveat is on the carrier and on every receipt (scope= line).

Evidence level for the execution route: the SSH/sudo/Secret Manager route has no hermetic seam, so the claims above cover the pure interfaces only. NEITHER ROW has a live receipt yet, and an earlier wording of this line said only the ntfy row did. The GitHub Actions run history for the fleet-converge workflow carries 295 runs back to 2026-08-15 and zero dispatches of microvm_controller_app_key_converge, the mode #11679 introduced on 2026-09-20 -- so the ControllerAppKey row this module inherits has never been dispatched either, and its latest ref has never resolved through the fetch join. That is what made the alias defect invisible: there was no live evidence either way, and a later review read the row as "already-live" and declined to raise it on that basis. Re-derive with gh run list --repo gunb-ai/gunbc --workflow fleet-converge.yml rather than taking it from here. Two operator steps come first: minting the token into Secret Manager, and ensuring approval_ntfy_publisher_token_accessor_row. Until then the mode refuses at the fetch and names the secret.

🤖 Generated with Claude Code

[gunbai-bot]

Addressed review 69483 in 5178db2, taking option (a): the extdeps authority now has a name form.

• extdeps.posix.identity adds PosixOwnerNames { user, group } and posix_owner_names_text. The : is still spelled only in that module; the note says why names are a separate fact from the numeric PosixOwnerSpec.
• extdeps.tools.chown adds chown_names_argv.
• The custody rows' ownership now is PosixOwnerNames: the local CustodyOwnership type is deleted rather than kept beside it. custody_file_chown_argv calls chown_names_argv.
• The receipt's owner= wire had the same re-spelling, and now goes through posix_owner_names_text too.

Witness host_credential_custody_converge is 37/37 on the change. The two claims that pin the argv and the receipt text also pass after the last edit.

gunbc.auth.approval_keyring_converge keyring_chown_argv still has the old shape. That isn't in this PR's scope, and it can move to chown_names_argv in a follow-up.

— sent from proud-fox-175

[gunbai-bot]

Follow-up on review 69483 in 38b2d1f: chown_argv now handles both numeric and named owners, and the one existing duplicate is moved onto it.

• extdeps.tools.chown chown_argv(owner: ChownOwner, path), where ChownOwner = ChownOwnerIds { spec: PosixOwnerSpec } | ChownOwnerNames { names: PosixOwnerNames }. The separate chown_names_argv from the previous commit is removed.
• Both forms render through extdeps.posix.identity posix_owner_pair_text, which is now the only place the : is written. Before this, posix_owner_spec_text and posix_owner_names_text each wrote their own.
• Callers:
  • gunbc.host.host_effect_realize and the srv3 witness wrap ChownOwnerIds.
  • The custody row and gunbc.auth.approval_keyring_converge keyring_chown_argv use ChownOwnerNames. The keyring argv also changes from a bare chown to the modeled /usr/bin/chown.
• There is no "chown" literal left in any .dag argv.

Witnesses: host_credential_custody_converge 37/37, srv3_principal_privilege 18/18, approval_keyring_converge 10/10.

— sent from proud-fox-175

[briansrls]

HOLD — exact head 5c07e5cf4856e9e5e79c16b6dea7d53745db062f.

The consolidation itself is well-shaped: one closed credential roster, one fleet-converge mode, row-derived file/directory permissions, host scope before fetch, and the permission-bits caveat retained on the authority and receipt. The new ntfy row cannot currently reach that machinery with a credential.

P0 — the ntfy latest SecretRef is incompatible with the fetcher’s exact-version join

The new row declares:

approval_ntfy_publisher_token_secret_ref =
  secret_ref_pin_version(..., version: "latest")

and the production entry fetches it through fetch_secret_ref_credential.

That fetcher deliberately refuses unless the identity returned by Secret Manager names the same exact version as the requested SecretRef. Its own authority records the measured wire behavior: AccessVersion canonicalizes the answer to a numeric resource such as:

projects/<number>/secrets/<id>/versions/<n>

gcp_resource_names_this_version admits the project-id/project-number spelling difference, but it retains ref.version unchanged. For a request whose version is latest, the accepted spellings therefore end in /versions/latest; the live response ends in /versions/<n>.

So the intended ordinary route is:

request versions/latest
-> response versions/17
-> SecretCredentialResolvedVersionMismatch
-> custody fetch refuses

The PR body already says there is no live ntfy receipt, so green hermetic CI does not contradict this source path.

Required repair

Do not weaken the exact-version wall globally. Choose one explicit policy:

1. Pinned delivery: the custody row names the numeric version to deliver; rotation advances that modeled version before convergence.
2. Alias-aware delivery: model latest as an alias request distinct from a pinned version, admit the returned numeric identity only after proving the same project and secret, and carry the resolved numeric version in the receipt. A pinned request for N answered by M must continue to refuse.

Whichever policy is selected, add discriminating controls covering:

• pinned N -> returned N: admitted;
• pinned N -> returned M: refused;
• latest -> numeric N: admitted only through the explicit alias arm;
• foreign project/secret -> numeric N: refused.

The current comment that latest is deliberate for rotation is a policy intention, but the existing fetch contract interprets it as an exact version string. Until those two facts are reconciled, the new ntfy delivery mode is guaranteed to stop at the Secret Manager read.

[gunbai-bot]

Three reviews (69522, 69535, 69542) independently reached the same blocking finding on version: "latest". I verified the mechanism in source and it is confirmed — but one piece of the corroboration is wrong, and correcting it makes the finding broader than any of the three stated. Flagging that before anyone fixes this, because it changes where the fix belongs.

The mechanism, confirmed

gcp_resource_names_this_version (extdeps/cloud/gcp/secret_ref.dag) builds both accepted spellings from ref.version, so a latest request is compared against .../versions/latest. secret_ref_credential.dag records, measured, that AccessVersion answers projects/<number>/secrets/<id>/versions/<n>. A numeric answer matches neither spelling, so resolved_identity_matches_request is false and SecretCredentialResolvedVersionMismatch fires.

Where the corroboration is wrong

Review 69542 says "every other production SecretRef pins a numeric version". That is not so. gunbai_ci_app_pem_secret (auth/github_apps.dag:56-60) is latest — and it is not a distant sibling, it is the ControllerAppKey row's own secret in this very roster (host_credential_custody_converge.dag:289), fetched through the same fetch_secret_ref_credential call at the same entry. The predecessor this module replaces did the same thing on main (microvm_controller_app_key_converge.dag:954).

Review 69535 saw this and drew the right conclusion — it marked the finding PLAUSIBLE rather than confirmed and named the discriminator: a live HELD receipt for the ControllerAppKey row would dissolve it.

So the finding is one of two things, and they need different fixes

Either:

1. The join really does refuse every latest — in which case the pre-existing controller-key delivery has never succeeded live either, and this PR is not introducing a dead row so much as inheriting one. The fix then belongs in gcp_resource_names_this_version (alias-aware resolution, proving same project and secret before accepting a resolved numeric answer, carrying that numeric identity into the receipt) — one place, correct for both rows and every other latest ref in the tree.

2. Something about the real response matches — in which case both rows are fine and all three findings dissolve together.

Pinning the ntfy row to a numeric version fixes neither case honestly: in case 1 it leaves the controller key broken beside it, and it makes every rotation a source edit for a row whose ref is shared with runner_host_deploy and ci_spec. That is the hand-enumerated-roster stall this PR exists to remove.

What settles it

One fact, and it is not in the repository: has the controller-key converge (old mode microvm_controller_app_key_converge) ever produced a HELD receipt on a live dispatch? I searched for a recorded receipt and there is none either way. I am not guessing at it — asserting GCP's alias behaviour from the join's shape would be the same "deduced from inferred" move this lane keeps catching.

Holding the PR at REQUEST_CHANGES until that is answered. The octal-consolidation fix from review 69522 is unrelated to this and stands (verified by mutation: the witness literals flip it red).

— sent from zesty-crane-846

[briansrls]

SOURCE APPROVE — live exact head e20b042528307db70cd6a5ced222c83fa434e746.

The requested 9379b48084… is no longer the PR head. I reviewed the current head, including the subsequent merge from main; the only merge conflict was the generated fleet-converge mode roster, and the current projection retains both sides' modes, uses host_credential_custody_converge, carries the closed credential choice, and contains no surviving old mode in the generated route.

The prior alias P0 is closed at the correct authority:

• SecretVersionSelector lives beside the SecretRef resource-name builder;
• resolve_returned_version proves the full project and secret before applying exact-versus-alias semantics;
• exact N→N is admitted, exact N→M is refused;
• latest→numeric N is admitted through the alias arm and carries N in the resolved identity;
• foreign project/secret answers and an echoed unresolved latest are refused;
• the credential fetch consumes that resolver, while verify_app_key_version explicitly refuses alias semantics as its exact-version policy.

The further repairs also hold:

• file readback octal derives from remote_file_mode_octal rather than a second literal;
• the directory mode arms and rendering live in gunbc.managed_directory, with the ntfy deployment and custody row consuming one declaration rather than a witness comparing two spellings;
• the old R2-origin row is no longer cited as a foreign-project wall, and the new authorable control supplies an independent foreign-project identity that actually discriminates the project join.

The two red witness files reported in the handoff are real coverage debt, but neither is in this PR's changed-file surface and the handoff reports the same failures with the branch changes stashed. I am not treating them as a regression of this change. They should be separately enrolled or repaired; a real red that no required lane reaches remains a floor-coverage problem.

One body-only precision correction is advisable: the evidence note says only the ntfy row lacks a live receipt, while the run census established that the controller-key mode has also never been dispatched. State that neither roster row currently has a live custody receipt. Do not move this approved source head merely for that metadata correction.

Landing gate: compiler and clippy are successful; the exact-head floor is still running as I write this. Freeze this SHA and merge/queue only after every required check for e20b0425… is terminal-success.