rotate-token: accept a raw value format and a tailscale-status verify probe #53

Closed
opened 2026-09-11 09:06:56 +01:00 by allod-agent · 0 comments
Member

Let the rotation registry describe a tailscale auth key truthfully, so a per-machine tailnet credential can be registered as a service: none group without borrowing Forgejo labels for its value shape and its verify probe.

Primary goals:

  • A raw value shape — format: raw means the plaintext is the value itself and nothing else. It rotates exactly as raw-forgejo-token does today, without a name that says Forgejo.
  • A tailnet verify probe — verify.type: tailscale-status prints tailscale status --peers=false for a nixos-host target and ssh <system> 'tailscale status --peers=false' for every other kind, next to the three probes that exist.
  • Validator and copy agree — validate_group_metadata, prepare_item, the encryption switch and print_group_verification all accept both names, and the sabotage fixture still proves an unknown format or probe is refused.
  • Tests — the fixture gains one none group whose credential uses raw and tailscale-status; a dry-run test asserts the printed verify line and a live rotation test asserts the decrypted plaintext is the new value, unchanged.

Current state and specifics

scripts/rotate-token limits format to raw-forgejo-token, credential-store-url and rclone-remote-stanza in validate_group_metadata (line 225), in prepare_item (line 335) and in the encryption switch (line 460), and limits verify.type to forge-token-verify, git-ls-remote and site-check in the validator (line 232) and in print_group_verification (line 1078). Each site dies on anything else. The header comment (lines 11 to 27) lists the formats.

allod secret create and allod secret rekey (allod/tools#182) read only credential and secret_path from a registry group, so a tailscale key registered with made-up labels lands and rekeys fine; only rotate-token --group refuses it later, with unsupported metadata. The design comment on allod/tools#182 says the registry "stops being Forgejo-shaped" after service became an enum, but the format and verify vocabularies are still Forgejo and rclone only. This is the first credential that fits neither.

The immediate consumer is a private deployment splitting its shared tailscale auth key into one reusable key per dev machine, each landed with allod secret create; its tracking issue lives in that deployment's tracker.

Scope

In: the two new names at every site that switches on them, the header comment, one sentence in docs/credentials.md naming the vocabulary, and the tests above. Out: renaming the registry file and export (an allod/secrets issue, per allod/tools#197); the Go port allod secret rotate (allod/tools#197), which must carry the same two names when it lands; retiring rotate-token (allod/nexus#52), which this does not advance or delay.

Let the rotation registry describe a tailscale auth key truthfully, so a per-machine tailnet credential can be registered as a `service: none` group without borrowing Forgejo labels for its value shape and its verify probe. Primary goals: - **A raw value shape** — `format: raw` means the plaintext is the value itself and nothing else. It rotates exactly as `raw-forgejo-token` does today, without a name that says Forgejo. - **A tailnet verify probe** — `verify.type: tailscale-status` prints `tailscale status --peers=false` for a `nixos-host` target and `ssh <system> 'tailscale status --peers=false'` for every other kind, next to the three probes that exist. - **Validator and copy agree** — `validate_group_metadata`, `prepare_item`, the encryption switch and `print_group_verification` all accept both names, and the sabotage fixture still proves an unknown format or probe is refused. - **Tests** — the fixture gains one `none` group whose credential uses `raw` and `tailscale-status`; a dry-run test asserts the printed verify line and a live rotation test asserts the decrypted plaintext is the new value, unchanged. ### Current state and specifics `scripts/rotate-token` limits `format` to `raw-forgejo-token`, `credential-store-url` and `rclone-remote-stanza` in `validate_group_metadata` (line 225), in `prepare_item` (line 335) and in the encryption switch (line 460), and limits `verify.type` to `forge-token-verify`, `git-ls-remote` and `site-check` in the validator (line 232) and in `print_group_verification` (line 1078). Each site dies on anything else. The header comment (lines 11 to 27) lists the formats. `allod secret create` and `allod secret rekey` (allod/tools#182) read only `credential` and `secret_path` from a registry group, so a tailscale key registered with made-up labels lands and rekeys fine; only `rotate-token --group` refuses it later, with `unsupported metadata`. The design comment on allod/tools#182 says the registry "stops being Forgejo-shaped" after `service` became an enum, but the format and verify vocabularies are still Forgejo and rclone only. This is the first credential that fits neither. The immediate consumer is a private deployment splitting its shared tailscale auth key into one reusable key per dev machine, each landed with `allod secret create`; its tracking issue lives in that deployment's tracker. ### Scope In: the two new names at every site that switches on them, the header comment, one sentence in `docs/credentials.md` naming the vocabulary, and the tests above. Out: renaming the registry file and export (an allod/secrets issue, per allod/tools#197); the Go port `allod secret rotate` (allod/tools#197), which must carry the same two names when it lands; retiring `rotate-token` (allod/nexus#52), which this does not advance or delay.
vnprc closed this issue 2026-09-11 21:00:01 +01:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
allod/nexus#53
No description provided.