Host keys and identities are not checked against the inventory machine list #43

New issue

Closed

opened 2026-10-07 18:40:19 +01:00 by vnprc-agent · 0 comments

vnprc-agent commented

2026-10-07 18:40:19 +01:00

Primary goals:

The two sets must agree — every machine in the consumed inventory has a machine-host-keys.json entry, and every entry names a machine that exists, each its own named refusal.
Sabotage proves it — one fixture per direction, so the check is shown to fail rather than assumed to.

Current state and specifics

flake.nix reads inventory.lib.machines, and checks/hypervisor-recipient-coverage.nix is the only check that reads real machines. It verifies recipient coverage for machines already present in both places; it never asserts the two sets are equal. Everything else derives from machine-host-keys.json's own attribute names, so the file is self-consistent whatever it contains.

Measured while adding the forge machine (allod/secrets#42): the full gate passed with forge present in the inventory and absent from this repository, and would equally pass with an entry here for a machine no inventory declares.

The failure this allows is not local. allod/archetypes machineConfigurations asserts identity keys equal machine keys, so a missing identity surfaces there as machines keys must exactly match identity keys — one repository's omission reported as another repository's error, at lock-bump time, with nothing naming the file to edit. A missing host key is quieter still: evaluation succeeds and provisioning fails on the machine.

Both halves of the slice-3 work hit this. The identity half was caught only because a lock bump was attempted; nothing would have caught a host-key entry left out.

Scope

In: the two refusals and their sabotage fixtures, in this repository, against the consumed inventory. Out: the hypervisor's own key, which is not a registry machine (nexus-host-key.json is its own source); and anything that would make this repository validate inventory's internal shape, which inventory already owns.

A host-key entry for a machine that does not exist, or a machine with no host-key entry, is accepted silently in both directions — so the mistake that stops a provision is invisible until the hypervisor tries it. Primary goals: - **The two sets must agree** — every machine in the consumed inventory has a `machine-host-keys.json` entry, and every entry names a machine that exists, each its own named refusal. - **Sabotage proves it** — one fixture per direction, so the check is shown to fail rather than assumed to. ### Current state and specifics `flake.nix` reads `inventory.lib.machines`, and `checks/hypervisor-recipient-coverage.nix` is the only check that reads real machines. It verifies recipient coverage for machines already present in both places; it never asserts the two sets are equal. Everything else derives from `machine-host-keys.json`'s own attribute names, so the file is self-consistent whatever it contains. Measured while adding the `forge` machine (allod/secrets#42): the full gate passed with `forge` present in the inventory and absent from this repository, and would equally pass with an entry here for a machine no inventory declares. The failure this allows is not local. `allod/archetypes` `machineConfigurations` asserts identity keys equal machine keys, so a missing identity surfaces there as `machines keys must exactly match identity keys` — one repository's omission reported as another repository's error, at lock-bump time, with nothing naming the file to edit. A missing *host key* is quieter still: evaluation succeeds and provisioning fails on the machine. Both halves of the slice-3 work hit this. The identity half was caught only because a lock bump was attempted; nothing would have caught a host-key entry left out. ### Scope In: the two refusals and their sabotage fixtures, in this repository, against the consumed inventory. Out: the hypervisor's own key, which is not a registry machine (`nexus-host-key.json` is its own source); and anything that would make this repository validate inventory's internal shape, which inventory already owns.

vnprc-agent referenced this issue from a commit

2026-10-07 19:26:19 +01:00

Add serviceVMs identity group for the forge VM