Derive the agent token and forge key entries so a forge-less fork carries no placeholder #40

New issue

Closed

opened 2026-10-05 20:19:01 +01:00 by vnprc-agent · 1 comment

vnprc-agent commented

2026-10-05 20:19:01 +01:00

The credential inventory hard-codes the agent-pr-token entry and secrets.nix hard-codes its recipient line, so a fork in which no dev VM has forge access (forgeAccess = false, which devIdentities already honours by handing the VM no token) still has to carry a token ciphertext to keep credential-inventory green. The same goes for the forge git key lines, which are spelled out per file rather than derived from forge-ssh-keys.json.

Proposal: derive both from the data that already decides them. The token entry and its recipient line exist only while some dev VM has forge access; the forge-key recipient lines come from the registry; the VM host-key lines come from machine-host-keys.json plus the hypervisor's own name. The template's evaluated output is unchanged. A forge-less fork then sets forgeAccess = false, empties forge-ssh-keys.json, deletes the two ciphertexts and the forge public key, and its checks pass with no placeholder secret anywhere.

Also makes forgeAccess explicit in the template identity, since a flag that is only ever defaulted is invisible to a fork.

Found during the public install walk.

The credential inventory hard-codes the `agent-pr-token` entry and `secrets.nix` hard-codes its recipient line, so a fork in which no dev VM has forge access (`forgeAccess = false`, which `devIdentities` already honours by handing the VM no token) still has to carry a token ciphertext to keep `credential-inventory` green. The same goes for the forge git key lines, which are spelled out per file rather than derived from `forge-ssh-keys.json`. Proposal: derive both from the data that already decides them. The token entry and its recipient line exist only while some dev VM has forge access; the forge-key recipient lines come from the registry; the VM host-key lines come from `machine-host-keys.json` plus the hypervisor's own name. The template's evaluated output is unchanged. A forge-less fork then sets `forgeAccess = false`, empties `forge-ssh-keys.json`, deletes the two ciphertexts and the forge public key, and its checks pass with no placeholder secret anywhere. Also makes `forgeAccess` explicit in the template identity, since a flag that is only ever defaulted is invisible to a fork. Found during the public install walk.

vnprc referenced this issue from a commit

2026-10-05 20:44:58 +01:00

Derive the agent token and forge key entries from the identity data

vnprc referenced this issue from a commit

2026-10-05 20:49:18 +01:00

flake.lock: update nexus, inventory, secrets

vnprc referenced this issue from a commit

2026-10-05 20:57:07 +01:00

flake.lock: update archetypes, inventory, secrets

allod-agent referenced this issue from allod/tools

2026-10-18 05:30:14 +01:00

secret declare: take the host recipient term from the target secrets.nix #275

allod-agent added the

landed?

label

2026-10-21 22:27:19 +01:00

allod-agent commented

2026-10-21 23:32:44 +01:00

Member

Landed on master in commit 07b0b1c: the agent token entry and its recipients are derived from lib/forge-access-vms.nix, forge-key and host-key recipient lines come from the registries, and the template identity says forgeAccess = true explicitly. Verified against the files on master today; closing as completed.

Landed on master in commit 07b0b1c: the agent token entry and its recipients are derived from lib/forge-access-vms.nix, forge-key and host-key recipient lines come from the registries, and the template identity says forgeAccess = true explicitly. Verified against the files on master today; closing as completed.

allod-agent

2026-10-21 23:32:45 +01:00