Rename the rotation registry to rotation-registry.json and lib.rotationRegistry #31

Merged

vnprc merged 4 commits from agent/rotation-registry-rename into master

2026-09-19 22:41:20 +01:00

allod-agent commented

2026-09-19 18:54:13 +01:00

Member

The rotation registry is renamed to say what it holds: the file forgejo-token-groups.json becomes rotation-registry.json and the flake export lib.forgejoTokenGroups becomes lib.rotationRegistry. What changes for a running machine: nothing yet; the registry's contents, validation, and every value consumers read are byte-identical, and the old export name stays as a deprecated alias of the new one for one compatibility window. What stays identical: the registry shape, the checks, and every other export. What proves it: the credential-registry and credential-inventory checks pass and both export names evaluate to the same JSON. If it is wrong, revert; the only consumer that notices the file rename before the alias is allod secret declare, which opens the file by name and lands next.

Landing order, as recorded on the issue: this PR first; then allod/tools, allod/nexus, and allod/archetypes, each reading lib.rotationRegistry with no fallback; then the deploy lock cascade advancing secrets before archetypes; then a final secrets PR removing the alias, which closes the issue. A deployment's private fork of allod/secrets must merge this rename before the new nexus or tools reads its checkout. allod/secrets PR 30 is open on the same two files; whichever lands second rebases.

Refs allod/secrets#22

Risk

R3. A cross-repo interface in the secrets repository is renamed. Residual: a consumer bumped to this commit without moving to the new name keeps working through the alias, and a consumer moved to the new name against an older secrets checkout fails loudly by attribute name; neither touches secret material.

Validation

Run by the integrator on the reviewed commit:

nix build .#checks.x86_64-linux.credential-registry .#checks.x86_64-linux.credential-inventory --no-link -L: exit 0.
nix eval --json .#lib.rotationRegistry | sha256sum and the same for .#lib.forgejoTokenGroups: identical hashes.
grep -rn -i 'forgejo-token-groups\|forgejoTokenGroups' . outside .git: only the alias line in flake.nix and its README row.

Cold review: gpt-5.6-sol via codex exec, default effort, read-only sandbox, on commit efc72c37. Findings and disposition:

Major, the file rename is a flag day while the flake comment claims a compatibility window. Discarded as a defect, the decision is deliberate and recorded on the issue: the alias covers the export, which is what evaluation-time consumers read; the file name is opened only by allod secret declare, which lands right after this.
Minor, the checks table still said "Forgejo credential registry". Fixed in c3eaf54.
Claim not supported, the README said service is forgejo or none inside a paragraph about what the check rejects, but the validator never reads service. Fixed in c3eaf54: the sentence now describes the field and says the check does not validate it and allod secret refuses other values. Adding validation is out of scope for the issue.
No missed consumers.

The fix commit was re-validated with the same three commands.

The rotation registry is renamed to say what it holds: the file `forgejo-token-groups.json` becomes `rotation-registry.json` and the flake export `lib.forgejoTokenGroups` becomes `lib.rotationRegistry`. What changes for a running machine: nothing yet; the registry's contents, validation, and every value consumers read are byte-identical, and the old export name stays as a deprecated alias of the new one for one compatibility window. What stays identical: the registry shape, the checks, and every other export. What proves it: the `credential-registry` and `credential-inventory` checks pass and both export names evaluate to the same JSON. If it is wrong, revert; the only consumer that notices the file rename before the alias is `allod secret declare`, which opens the file by name and lands next. Landing order, as recorded on the issue: this PR first; then allod/tools, allod/nexus, and allod/archetypes, each reading `lib.rotationRegistry` with no fallback; then the deploy lock cascade advancing secrets before archetypes; then a final secrets PR removing the alias, which closes the issue. A deployment's private fork of allod/secrets must merge this rename before the new nexus or tools reads its checkout. allod/secrets PR 30 is open on the same two files; whichever lands second rebases. Refs allod/secrets#22 ## Risk R3. A cross-repo interface in the secrets repository is renamed. Residual: a consumer bumped to this commit without moving to the new name keeps working through the alias, and a consumer moved to the new name against an older secrets checkout fails loudly by attribute name; neither touches secret material. ## Validation Run by the integrator on the reviewed commit: - `nix build .#checks.x86_64-linux.credential-registry .#checks.x86_64-linux.credential-inventory --no-link -L`: exit 0. - `nix eval --json .#lib.rotationRegistry | sha256sum` and the same for `.#lib.forgejoTokenGroups`: identical hashes. - `grep -rn -i 'forgejo-token-groups\|forgejoTokenGroups' .` outside `.git`: only the alias line in `flake.nix` and its README row. Cold review: `gpt-5.6-sol` via `codex exec`, default effort, read-only sandbox, on commit efc72c37. Findings and disposition: - Major, the file rename is a flag day while the flake comment claims a compatibility window. Discarded as a defect, the decision is deliberate and recorded on the issue: the alias covers the export, which is what evaluation-time consumers read; the file name is opened only by `allod secret declare`, which lands right after this. - Minor, the checks table still said "Forgejo credential registry". Fixed in c3eaf54. - Claim not supported, the README said `service` is `forgejo` or `none` inside a paragraph about what the check rejects, but the validator never reads `service`. Fixed in c3eaf54: the sentence now describes the field and says the check does not validate it and `allod secret` refuses other values. Adding validation is out of scope for the issue. - No missed consumers. The fix commit was re-validated with the same three commands.

allod-agent added 2 commits

2026-09-19 18:54:13 +01:00

Rename the rotation registry from forgejo-token-groups.json to rotation-registry.json efc72c376a

Export lib.rotationRegistry as the primary name and keep lib.forgejoTokenGroups
as a deprecated alias for one compatibility window while archetypes, nexus,
and tools move over. README updated to describe a credential rotation
registry instead of a Forgejo-only deployment map.

Refs allod/secrets#22

README: name the rotation registry consistently and scope the service claim c3eaf542da

Refs allod/secrets#22

allod-agent referenced this pull request from allod/nexus

2026-09-19 18:54:23 +01:00

refresh-local-auth: read the renamed rotation registry export #60

allod-agent referenced this pull request from allod/tools

2026-09-19 18:54:27 +01:00

allod secret: read the rotation registry as rotation-registry.json and lib.rotationRegistry #219

allod-agent referenced this pull request from allod/archetypes

2026-09-19 18:56:06 +01:00

credential-profiles: read secrets.lib.rotationRegistry #78

allod-agent referenced this pull request

2026-09-19 18:56:22 +01:00

Rename the rotation registry: forgejo-token-groups.json and lib.forgejoTokenGroups no longer say what they hold #22

allod-agent added 2 commits

2026-09-19 22:23:10 +01:00

Merge remote-tracking branch 'origin/master' into agent/rotation-registry-rename 0f92a3858b

# Conflicts:
#	README.md
#	flake.nix

flake.nix: one rotationRegistry binding after merging the credential-store URL export cc705d4e64

Refs allod/secrets#22

allod-agent commented

2026-09-19 22:23:13 +01:00

Author

Member

Master moved under this branch when allod/secrets PR 30 landed, and both PRs edit the export block of flake.nix and the README tables, so the branch now carries a merge of master (0f92a38) plus one follow-up (cc705d4). The follow-up exists because the merge left two validations of the same file: PR 30 had introduced its own forgejoTokenGroups let binding, and our rotationRegistry binding sat beside it. There is now one binding, rotationRegistry, feeding lib.rotationRegistry, the deprecated lib.forgejoTokenGroups alias, lib.localAuthRefreshSources, and the local-auth-refresh check.

Validation on cc705d4, run by the integrator: credential-registry, credential-inventory, and local-auth-refresh checks build (exit 0); lib.rotationRegistry and lib.forgejoTokenGroups hash identically and unchanged from the reviewed commit; lib.credentialStoreUrl and lib.localAuthRefreshSources evaluate.

Master moved under this branch when allod/secrets PR 30 landed, and both PRs edit the export block of `flake.nix` and the README tables, so the branch now carries a merge of master (0f92a38) plus one follow-up (cc705d4). The follow-up exists because the merge left two validations of the same file: PR 30 had introduced its own `forgejoTokenGroups` let binding, and our `rotationRegistry` binding sat beside it. There is now one binding, `rotationRegistry`, feeding `lib.rotationRegistry`, the deprecated `lib.forgejoTokenGroups` alias, `lib.localAuthRefreshSources`, and the `local-auth-refresh` check. Validation on cc705d4, run by the integrator: `credential-registry`, `credential-inventory`, and `local-auth-refresh` checks build (exit 0); `lib.rotationRegistry` and `lib.forgejoTokenGroups` hash identically and unchanged from the reviewed commit; `lib.credentialStoreUrl` and `lib.localAuthRefreshSources` evaluate.