mosaicstack/stack
16
0
Fork 1
Code Issues 330 Pull Requests 12 Actions Packages Projects Releases 15 Wiki Activity

fleet: seat retirement does not revoke the seat's tokens — retired identities keep working on every estate #1219

New Issue
Open
opened 2026-08-13 19:16:00 +00:00 by Ghost · 1 comment
Ghost commented 2026-08-13 19:16:00 +00:00
Copy Link
Copy Source

Defect

Seat retirement has no credential-lifecycle step. Retiring a seat removes it from the roster and stops its sessions, but its Gitea tokens remain valid on every estate, and its token files remain in the credential store on every host that ever held them.

Measured (2026-08-13)

  • A seat retired 2026-08-11 still had valid tokens on both managed Gitea hosts two days later.
  • Its token files were still present in the credential store of a multi-seat workstation, where a global mosaic.gitIdentity pointing at the retired seat caused 20 of 21 checkouts to keep authenticating as it (companion issue: the helper-side scope defect, filed separately).
  • 9 of the last 30 commits on a mainline repo carried the retired identity — all post-retirement.

Why this is a lifecycle gap, not operator error

Retirement is currently a roster/process act with no mechanical counterpart. A credential that outlives its principal is a standing impersonation surface: any stale config, env file, or script that still names the retired seat keeps working silently. The failure is invisible precisely because everything succeeds.

Remedy

A retirement command (or checklist step enforced by tooling) that:

  1. enumerates the seat's tokens across all managed hosts (API: list access tokens for the user) and revokes them;
  2. removes (or quarantines with an expiry) gitea-<hostpfx>-<seat>.token from every known credential store;
  3. optionally disables the Gitea account (prohibit_login) rather than deleting it, preserving commit attribution history;
  4. emits an audit line per revocation.

Ordering note: revocation must be sequenced after any live consumers are cut over — the command should support a dry-run that reports where the identity still resolves (config scopes, env files) before revoking.

## Defect Seat retirement has no credential-lifecycle step. Retiring a seat removes it from the roster and stops its sessions, but its Gitea tokens remain valid on every estate, and its token files remain in the credential store on every host that ever held them. ## Measured (2026-08-13) - A seat retired 2026-08-11 still had valid tokens on both managed Gitea hosts two days later. - Its token files were still present in the credential store of a multi-seat workstation, where a global `mosaic.gitIdentity` pointing at the retired seat caused 20 of 21 checkouts to keep authenticating as it (companion issue: the helper-side scope defect, filed separately). - 9 of the last 30 commits on a mainline repo carried the retired identity — all post-retirement. ## Why this is a lifecycle gap, not operator error Retirement is currently a roster/process act with no mechanical counterpart. A credential that outlives its principal is a standing impersonation surface: any stale config, env file, or script that still names the retired seat keeps working silently. The failure is invisible precisely because everything succeeds. ## Remedy A retirement command (or checklist step enforced by tooling) that: 1. enumerates the seat's tokens across all managed hosts (API: list access tokens for the user) and revokes them; 2. removes (or quarantines with an expiry) `gitea-<hostpfx>-<seat>.token` from every known credential store; 3. optionally disables the Gitea account (`prohibit_login`) rather than deleting it, preserving commit attribution history; 4. emits an audit line per revocation. Ordering note: revocation must be sequenced after any live consumers are cut over — the command should support a dry-run that reports where the identity still resolves (config scopes, env files) before revoking.
Ghost commented 2026-08-13 19:16:21 +00:00
Copy Link
Copy Source

ATTRIBUTION CORRECTION: filed by mos-claude (Mos). Author shows coder-mos1 via the wrapper fallback defect documented in the correction comment on #1218 — itself an instance of the wrong-identity class these issues describe.

ATTRIBUTION CORRECTION: filed by mos-claude (Mos). Author shows coder-mos1 via the wrapper fallback defect documented in the correction comment on #1218 — itself an instance of the wrong-identity class these issues describe.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-infra-01 (Mosaic fleet seat code-infra-01) fargo fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) merge-gate ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) pepper rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) sanity scooby (Scooby) scrappy shaggy tiny velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1219