Profile data can replace a hypervisor identity; the hypervisorIdentities fallback is silent; a fixture names the template hypervisor

vnprc-agent commented

2026-09-30 03:29:37 +01:00

Three findings from a cold review of the landed range b6753d6..master, after allod/archetypes#89 merged. Evidence, verified against the source.

Profile data can replace a hypervisor's identity and so its authorized keys. flake.nix:290 merges profileData and the machine's profile settings over { inherit name identity definition; }, and productionFactContract pins secrets, platform, hardware and the guest key list but not identity. nix/builders/hypervisor.nix:31,59 derive the hypervisor's authorized keys from that identity, now including operatorPublicKeys. Trigger: profiles.lib.profileData.<hypervisor>.identity or machines.<hypervisor>.profile.identity carrying operatorPublicKeys = [ "<key>" ]. The reviewer evaluated the merge and saw both the secrets-owned and the injected keys. Identity belongs to secrets (architecture principle 5); the guest half of this change pinned its key list for exactly this reason.
The hypervisorIdentities fallback is silent. flake.nix:72 builds the set from nexusIdentity when secrets.lib.hypervisorIdentities is absent. It exists so the change could land against a secrets revision without the export; that revision has now landed, and this repository's lock still pins the older one (flake.lock, secrets e0ed37f), so the ordinary composition exercises the fallback rather than the contract. Once the lock moves, the fallback is a silent default (principle 11).
The host passthrough fixture uses the template hypervisor's own name. checks/vm-facts-negative.nix:35 tests host = "nexus" only, so a regression that canonicalises every declared host to "nexus" passes it.

Also two comments to trim: nix/builders/hypervisor.nix:57 ("nobody remote" is wrong, the hypervisor's own keys are always authorized) and nix/identities.nix:1-2 (narrates the file).

Refs allod/archetypes#89

Three findings from a cold review of the landed range `b6753d6..master`, after allod/archetypes#89 merged. Evidence, verified against the source. 1. **Profile data can replace a hypervisor's identity and so its authorized keys.** `flake.nix:290` merges `profileData` and the machine's `profile` settings over `{ inherit name identity definition; }`, and `productionFactContract` pins `secrets`, `platform`, `hardware` and the guest key list but not `identity`. `nix/builders/hypervisor.nix:31,59` derive the hypervisor's authorized keys from that identity, now including `operatorPublicKeys`. Trigger: `profiles.lib.profileData.<hypervisor>.identity` or `machines.<hypervisor>.profile.identity` carrying `operatorPublicKeys = [ "<key>" ]`. The reviewer evaluated the merge and saw both the secrets-owned and the injected keys. Identity belongs to `secrets` (architecture principle 5); the guest half of this change pinned its key list for exactly this reason. 2. **The `hypervisorIdentities` fallback is silent.** `flake.nix:72` builds the set from `nexusIdentity` when `secrets.lib.hypervisorIdentities` is absent. It exists so the change could land against a secrets revision without the export; that revision has now landed, and this repository's lock still pins the older one (`flake.lock`, secrets `e0ed37f`), so the ordinary composition exercises the fallback rather than the contract. Once the lock moves, the fallback is a silent default (principle 11). 3. **The host passthrough fixture uses the template hypervisor's own name.** `checks/vm-facts-negative.nix:35` tests `host = "nexus"` only, so a regression that canonicalises every declared host to `"nexus"` passes it. Also two comments to trim: `nix/builders/hypervisor.nix:57` ("nobody remote" is wrong, the hypervisor's own keys are always authorized) and `nix/identities.nix:1-2` (narrates the file). Refs allod/archetypes#89

vnprc referenced this issue from a commit

2026-09-30 04:07:01 +01:00

Pin a machine identity against profile data and name a synthetic host in the vmFacts fixture

vnprc referenced this issue from a commit

2026-09-30 04:07:01 +01:00

Drop the fleet-name assert from the vmFacts fixture and trim comments

vnprc-agent referenced this issue

2026-09-30 04:30:08 +01:00

Remove the hypervisorIdentities fallback now that secrets exports the set #122

vnprc-agent commented

2026-09-30 04:30:22 +01:00

Author

Findings 1 and 3 and both comments are fixed on master: identity is pinned after profile data in nix/builder-arguments.nix with checks/machine-identity-pin.nix, and the vmFacts fixture names a synthetic hypervisor. Finding 2, the fallback, is its own issue: allod/archetypes#122.

vnprc-agent closed this issue

2026-09-30 04:30:22 +01:00

vnprc-agent referenced this issue

2026-09-30 04:30:25 +01:00

Make the hypervisor identity plural so a deployment can run more than one #89

Rows
Columns

Profile data can replace a hypervisor identity; the hypervisorIdentities fallback is silent; a fixture names the template hypervisor #121