Project a dev VM's own external SSH aliases onto devIdentities #34
No reviewers
Labels
No labels
blocked
bug
decision
duplicate
enhancement
handoff
help wanted
invalid
landed?
question
ready-to-merge
stale
wontfix
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
allod/secrets!34
Loading…
Reference in a new issue
No description provided.
Delete branch "agent/dev-vm-ssh-aliases"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The template's dev machine declares one external SSH alias of its own, and the identity that every dev VM is built from gains the field the framework reads for such aliases:
devIdentities.<vm>.sshHosts, projected fromdevVMs.<vm>.sshHostswith the VM's own key andidentitiesOnlyfilled in. On a running machine nothing changes until a deploy lock also carries the framework change (allod/archetypes#85); against the current framework the field is inert. The projection refuses, at evaluation and naming the machine and alias, anything that could capture or replace the VM's forge entry: an alias naming the forge host or any machine of the deployment (compared case-insensitively, as OpenSSH matches host patterns), an alias that is not one literal token, and an entry without a hostname. A machine that declares no aliases projects to an empty set, so a fork that predates the field composes unchanged. A new check proves each refusal fires on sabotaged input. Merge this before allod/archetypes#85: that branch then bumps its ownsecretslock so its composed check sees the template alias. If it is wrong, revert this PR.What changes
identity.nix:devVMs.allod-dev.sshHosts.example-build-cache(192.0.2.40, usercache,extraOptions.HostKeyAlias).lib/dev-ssh-hosts.nix(new):reservedNamesandproject; exported aslib.projectDevSshHostsso a downstream fork calls the same rules rather than respelling them.flake.nix:devIdentities.<vm>.sshHostsfrom the projection; thedev-ssh-hostscheck.README.md: the new check, the new export, andsshHostsin thelib.devIdentitiesrow.Risk
R2. A new validator on public template data with a new consumer in the framework; the refusals are the security-relevant part and each has a sabotage witness. The worst credible failure after validation is a deployment's real entry the projection rejects, which is a loud evaluation error naming the machine and alias at the lock bump. Rollback is a revert.
Validation
Run by the integrator at
255af16:nix flake checkexits 0 withdev-ssh-hostsamong the built checks (worker run); the check was shown failing when one refusal's expectation was inverted, then reverted.*,a b,Host x, an entry with no hostname, an entry that is a string.nix eval .#lib.devIdentities.allod-dev.sshHosts --jsonprints the entry withidentityFile~/.ssh/allod_vmandidentitiesOnlytrue; the record's other keys are unchanged from master.allod-devrenders the alias beside its forge block, both keyed to~/.ssh/allod_vm, andnexusis byte-identical to the current lock.Cold cross-family review:
gpt-5.6-solviacodex exec, reasoning effortxhigh, read this diff at72e0bectogether with the allod/archetypes#85 diff (Claude-family workers authored both). Three findings concerned this projection, all marked blocker, all confirmed and fixed in255af16:extraOptions.headerand newlines in string fields could open a block that captures the forge entry on the VM, now refused; aliases differing only by case both matched one host, now refused; the third, the framework's own fallback comparison, is fixed on the archetypes side. Each new refusal has a sabotage witness in thedev-ssh-hostscheck. No second reading follows the fix round; the fixes are settled by the rebuilt check and the by-hand refusal texts.Refs allod/archetypes#83
Refs allod/strategy#57