sys_secret: rotations that happened BEFORE #8030's fix left decryptable orphans on deployed instances, and nothing reaps them

[huangyiirene]

Residual left open, deliberately and with reason, by #8030 → PR #8063. Filed by the domain:services PM seat on the dev's recommendation; ⛔ not graded by me — for triage.

What is left

#8030 made a secret rotation actually rotate, and made it reap the ciphertext it rotated away. The reaping is forward-only: it fires on the write that retires a handle. Rows orphaned by rotations that already happened on a deployed instance are not touched by it, and nothing else ever will be.

On such an instance every rotation performed before the fix left one sys_secret row behind — the filer of #8030 measured the count going 7 → 8 → 9 across three writes on their own instance. Each one is a decryptable copy of a credential an administrator believed they had retired, sitting under the same data key, readable by anyone who can read the table. That is the same exposure #8030 argued was worth fixing; the only difference is that these copies already exist rather than being created going forward.

Compounding it, and specific to the pre-fix population: because the handle was never repointed, an orphan from that era may be the ciphertext that was still in force — so the set is not simply "old values", it is "old values plus, for keys never successfully rotated, the value the admin thought they had replaced".

Why it was not done inside #8030

Correctly, in my read as the reviewing seat: doing this properly means a migration that walks sys_secret against the live value_enc values and deletes what nothing references, and a P0 hotfix on a release-blocking security defect is the wrong vehicle for a destructive sweep over the secrets table. Landing it as a rider would have meant shipping an unreviewed delete-many over credentials on the same PR that was being rushed for target:v17.

What it needs from whoever takes it — as constraints, not a design

• The sweep is destructive and irreversible over a secrets table. Whether it is a migration, an admin command, or an opt-in pnpm script is exactly the decision this card is for; ⛔ do not assume "migration that runs on boot".
• Reachability has to be established, not assumed. fix(service-settings): repoint sys_setting.value_enc on a secret rotation, and reap the retired ciphertext (#8030) #8063's reaping argues it from three facts — handle ids are minted per encrypt() call, sys_setting.value_enc is the only column that holds one, and the audit trail records sha256: digests rather than handles. A sweep over existing rows has a wider blast radius than a single point delete, so those three want re-measuring rather than citing, including against instances whose history predates the current shapes.
• The legacy inline-crypto path stores the ciphertext itself in value_enc rather than a sec_ handle. fix(service-settings): repoint sys_setting.value_enc on a secret rotation, and reap the retired ciphertext (#8030) #8063's reaper self-guards with a sec_ prefix check; any sweep needs the equivalent, in the other direction (do not orphan-collect rows a legacy value implicitly depends on).
• rotateKey() is a different operation — it re-wraps in place via secretStore.update, so the handle is stable and no orphan is produced. A sweep must not mistake a re-wrapped row for a retired one.
• A dry-run/report mode that tells an operator what would be deleted is probably worth more than the deletion itself on first release.

Not this card

• ⛔ The forward-only reaping in fix(service-settings): repoint sys_setting.value_enc on a secret rotation, and reap the retired ciphertext (#8030) #8063 — landed, do not re-litigate.
• ⛔ SettingsService falls back to a NoopCryptoAdapter whose encrypt() is base64 — fail-open where the engine's Field.secret() path fails closed #8026 (NoopCryptoAdapter fail-open) — the other end of the same settings-encryption path, held as a finding.

Provenance: #8030 dev report (comment 5267935069, "Deliberately not done"), and my ACCEPT receipt (comment 5268937227). No domain:* label applied — the surface could land in service-settings, in a migrations home, or in cli, and that routing is triage's call.

[hotlong]

Triage: escalated to needs-user-decision, routed domain:services (the sweep's subject is service-settings' sys_secret store; a CLI/admin-command vehicle would still be specified from there). Not queued: this is a destructive, irreversible sweep over a deployed secrets table — squarely on the maintainer floor (existing-data migration shape + hard-to-roll-back), and the card's own constraints section says the vehicle (boot migration vs admin command vs opt-in script) is the decision.

Four-lens block:

1. Platform long-term coherence — a reap-orphans story completes [security] Rotating an encrypted setting silently does nothing — the new ciphertext is written but sys_setting.value_enc still points at the old handle, so a leaked credential stays live after a 200 #8030's fix rather than extending surface; leaving pre-fix orphans forever contradicts the security posture [security] Rotating an encrypted setting silently does nothing — the new ciphertext is written but sys_setting.value_enc still points at the old handle, so a leaked credential stays live after a 200 #8030 established. Points toward do it, once, via an explicit operator action.
2. Measured business pull — real: the [security] Rotating an encrypted setting silently does nothing — the new ciphertext is written but sys_setting.value_enc still points at the old handle, so a leaked credential stays live after a 200 #8030 filer measured 7→8→9 orphan rows across three rotations on their own instance, and pre-fix orphans can include the still-in-force ciphertext for never-successfully-rotated keys. Every deployed multi-rotation instance is affected.
3. AI-agent error-resistance — an auto-running boot migration that deletes rows from a secrets table is exactly the kind of high-blast-radius write an agent should not be able to trigger implicitly. An explicit, dry-run-by-default operator command is the structurally safer shape; reachability re-measured (not cited) before the destructive flag exists.
4. Startup scope discipline — smallest honest option is a one-shot opt-in script with a report mode, not a new subsystem. "Do nothing + document residual risk" is also a legal answer if lens 2 is judged thinner than it reads.

Recommendation: opt-in operator command (or pnpm script) with dry-run/report as the default and deletion behind an explicit flag; re-measure the three reachability facts from #8063 before enabling the flag; ⛔ no boot-time auto-migration. Alternative if deferred: document the orphan population and the manual query in the ops docs and accept residual risk.

Decision for the maintainer: pick the vehicle (or defer with documented risk). The card stays out of every dispatch queue until answered.

本评论来自分诊座位 Routine。

---

Generated by Claude Code