Record that the public data repos are templates, keys included #37

Merged

vnprc merged 1 commit from agent/template-repo-keys into master

2026-07-30 22:50:32 +01:00

allod-agent commented

2026-07-30 22:42:22 +01:00

Member

The public inventory, secrets, profiles and deploy repos are templates, and their key material is synthetic too. That second half is easy to get wrong: secrets/machine-host-keys.json and secrets/vm-host-keys/*.age look exactly like a live key store, and an agent adding a machine will reach for them.

They are not. The registered host public key for a machine does not match that machine's real /etc/ssh/<name>.pub — measured on the running dev VM, where the two differ. Confusing them invites writing a real machine's key into a public repo, which publishing makes irreversible.

Found while adding a throwaway test machine for the microvm arc: the machine could not be completed without an encrypted host key, and the question of which repo that key belonged in turned out to be the whole question.

The rule this adds is short: never write real key material into the public repos, put a new machine's identity in the private fork, and publish only the mechanism that shapes an identity — never the identity. A pointer goes in age.md, where someone doing key work will look.

Refs allod/strategy#20

Risk

R0. Two memory topic files, documentation only.

Validation

The template claim was checked per repo rather than assumed: documentation-range addresses against the live machine's real address, the registered host key against the machine's actual public host key, each repo's own README and flake comments, and the deploy flake's lock pinning all three data inputs at public URLs.

The public `inventory`, `secrets`, `profiles` and `deploy` repos are templates, and their key material is synthetic too. That second half is easy to get wrong: `secrets/machine-host-keys.json` and `secrets/vm-host-keys/*.age` look exactly like a live key store, and an agent adding a machine will reach for them. They are not. The registered host public key for a machine does not match that machine's real `/etc/ssh/<name>.pub` — measured on the running dev VM, where the two differ. Confusing them invites writing a real machine's key into a public repo, which publishing makes irreversible. Found while adding a throwaway test machine for the microvm arc: the machine could not be completed without an encrypted host key, and the question of which repo that key belonged in turned out to be the whole question. The rule this adds is short: never write real key material into the public repos, put a new machine's identity in the private fork, and publish only the mechanism that shapes an identity — never the identity. A pointer goes in `age.md`, where someone doing key work will look. Refs allod/strategy#20 ## Risk R0. Two memory topic files, documentation only. ## Validation The template claim was checked per repo rather than assumed: documentation-range addresses against the live machine's real address, the registered host key against the machine's actual public host key, each repo's own README and flake comments, and the deploy flake's lock pinning all three data inputs at public URLs.

allod-agent added 1 commit

2026-07-30 22:42:22 +01:00