[security] GET /api/v1/meta/:type/:name/diff serves stored credential VALUES — a plane the per-type item redactor cannot reach

[qq9340100]

Found while implementing #8154 (the metadata read path's per-type redaction hook). Filed rather than fixed: #8154's scope is settled by ruling to four item-serving exits plus the saveMetaItem carry-forward, and this exit needs a different decision, not the same call one line over. Not assigned — recording, not starting.

What leaks

ObjectStackProtocolImplementation.diffMetaItem (packages/metadata-protocol/src/protocol.ts) reads two stored bodies — history rows straight out of sys_metadata_history, and the current active row via repo.get(), which is documented VERBATIM (no conversion, no redaction) — runs diffShallow over them, and returns:

{ added: [{ path, value }], removed: [{ path, value }], changed: [{ path, from, to }] }

Those are stored body values. It is routed and live: packages/rest/src/rest-server.ts mounts GET ${metaPath}/:type/:name/diff and answers res.json(result) unmodified.

So for a pre-#8078 datasource row whose credential changed between two versions, the response carries something of the form { path: 'config.password', from: '…', to: '…' } in cleartext — and for a row where the credential was added, an added entry with the same value.

Why #8154's hook does not reach it

#8154 consumes getMetadataTypeRedactor (#8300) and applies it to whole item bodies at the four serving exits. A diff is not an item body: it is a list of (path, value) triples, so there is no body for the item-level redactor to take. The same reason #7990's data-API plane is a separate card applies here — same stored bytes, different plane.

Confirmed not a duplicate: searched open issues by keyword (diffMetaItem, diff endpoint, redaction, history, credential) and by file path before filing. #7990 owns the ordinary data API over sys_metadata; #8154 owns the four item exits; neither names this one.

Why it is not a one-liner — the decision this needs

Redacting both bodies before diffShallow is the obvious fix and it is not obviously right: two redacted bodies differ in nothing at a redacted path, so a credential rotation becomes an invisible no-diff. The version history is exactly where an operator would look to answer "when did this credential change, and by whom" — and #8154's own _diagnostics ordering ruling exists because a redaction that silently deleted an operator's inventory was the worse outcome. Plausible options, none free:

• A — redact both bodies before diffing. Simple, reuses the seam. Cost: rotations vanish from history entirely.
• B — diff raw, then redact the emitted value / from / to at any path the type's redactor names, keeping the path and a "changed" signal. Keeps the audit fact, drops the secret. Cost: needs a path-level projection the registry does not expose today (redactedKeys is item-relative and per-body, so this is a real derivation, not a call).
• C — refuse the diff for types that carry a redactor unless the caller holds a stronger permission. Cost: takes a working Studio affordance away from the rows most likely to need inspecting.

B looks right to me on #8154's own reasoning (preserve the operator's ability to enumerate, remove only the secret), but I did not measure it and it is not my call to take here.

Also measured while in the area, so nobody re-measures it

Both were owed by #8154 and are recorded there too:

• SysMetadataRepository.getByHash — an ADR-0009 MetadataRepository contract method implemented by four repositories, with no production caller anywhere in the repo: every reference outside the implementations is the contract suite, unit tests, or a docblock. It cannot serve a body to anyone today. Worth knowing when a consumer is eventually wired — the redaction belongs at that consumer's exit, not in the repository, whose raw get() the connect path and the write path both depend on.
• SysMetadataRepository.restoreVersion — a WRITE. Both callers (rollbackMetaItem, revertCommit) return receipts (success / version / seq / restoredFromVersion / message) and no body; the restored body reaches only applyRegistryWriteThrough, which must stay raw. No leak, and redacting there would corrupt the restored row.

Related: #8154, #7990, #8078, #8081.

---

Generated by Claude Code

[hotlong]

Triage: lands in packages/metadata-protocol/src/protocol.ts (diffMetaItem) ⇒ domain:metadata. Type Bug. Escalated to needs-user-decision.

Why this is escalated and not adjudicated in the repair lane. The mechanical boundary test alone would call it a repair (a leak narrows toward declared-=-enforced). But the four prisms split on the route, and a split is the escalation trigger — the three options trade an audit capability against a secret, and that trade is a product call, not a code detail.

⏱ Time-sensitive framing the maintainer should have: this is a routed, live GA endpoint (GET /api/v1/meta/:type/:name/diff → res.json(result) unmodified) serving stored credential values in cleartext. Whatever the eventual route, the leak is open while this sits in the box.

Four-prism block

• ① Platform long-term coherence — B. A path-level redaction projection is the general answer for every non-body plane (this endpoint, [security] sys_metadata.metadata is a general cleartext sink: any authored artefact whose schema permits an inline credential lands it there (datasource config.password, connector authentication) #7990's data plane, anything future that emits (path, value) rather than an item). A reuses the existing seam with no new machinery and is the more coherent small move; C shrinks the surface instead of solving it. Leans B long-term, A short-term.
• ② Measured business pull — B. The named, concrete use is an operator asking "when did this credential change, and by whom" — version history is exactly where that is answered. A destroys that: two redacted bodies differ in nothing at a redacted path, so a credential rotation becomes an invisible no-diff. Note the pull is for the audit fact, not the secret's value, which is precisely what B separates.
• ③ AI-agent error-resistance — B or C, ⛔ not A. A makes a real event (a rotation) render as "nothing changed" — silent tolerance, the failure shape the platform rejects. C refuses loudly. A is the only option that lies.
• ④ Startup scope discipline — A or C. B is a genuine derivation, not a call: redactedKeys is item-relative and per-body, so B builds and maintains new machinery. C is removal-shaped and cheapest to get right.

Split: ①④ favour A/C, ②③ favour B ⇒ escalated.

Recommendation

Stop the leak on the cheap route now, and file B as the follow-up rather than holding an open credential exposure while the path-level projection is designed. Of the two cheap routes, C (refuse the diff for redactor-carrying types) is preferable to A, because C is honest about what it took away while A silently converts a rotation into a no-diff — and a no-diff is the reading an operator will act on. If C's affordance loss is judged too expensive for Studio, A is acceptable only paired with B as a committed follow-up card.

Two questions that would settle it in one sitting:

1. Is the Studio diff view load-bearing for credential-carrying types today, or is it mostly used on ordinary metadata? (If the latter, C costs almost nothing.)
2. Should the follow-up path-level projection be scoped to this endpoint, or specified once for every non-body plane including [security] sys_metadata.metadata is a general cleartext sink: any authored artefact whose schema permits an inline credential lands it there (datasource config.password, connector authentication) #7990?

Recorded from the card so it is not re-measured

SysMetadataRepository.getByHash — contract method, no production caller; redaction belongs at a future consumer's exit, not in the repository. restoreVersion — a WRITE returning receipts only, no leak, and redacting there would corrupt the restored row. Both already recorded on #8154.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (delegated adjudication; delegation 2026-08-15 verbatim 「决策你直接帮我做」, batch confirmed 「同意」)

Ruled: Option B — diff raw, then redact emitted values at redactor-named paths, keeping the path and the "changed" signal.

Rationale (four-prism):

1. Platform coherence — the redactor's path naming is already the contract; the diff endpoint reuses that single source of naming rather than minting a second redaction rule set.
2. Business pull — the fact a rotation audit needs is "this credential changed in this version". B preserves it. Option A (redact before diffing) collapses old and new values into the same placeholder, so the changed-signal itself disappears — the one fact the feature exists to serve.
3. AI error-resistance — output-side filtering leaves the diff algorithm's comparison semantics untouched; A mutates data before comparison and opens a class of polluted-comparison bugs.
4. Startup scope — Option C (refuse to diff objects carrying credentials) amputates the feature; cost exceeds benefit.

Implementation notes for the dispatching seat:

• Redaction applies to emitted values only; the path and a changed/unchanged marker survive.
• ⛔ Both sides of the diff must be redacted on output — leaking either the old or the new value defeats the point.
• Pin with a test where a credential value changes: the diff must show the path as changed and neither value.

Label flipped needs-user-decision → pm:queue. Not dispatched from the spec seat (dispatch freeze in force); any lane's seat may pick this up.

---

Generated by Claude Code