fix(service-datasource): stop serving stored credentials on the datasource read path, and fix the false "credential-stripped" claim (#8081)

[huangyiirene]

Closes nothing on its own — #8081 stays open until scope items 3/4/5 are dispositioned, and #7990 stays open behind it. Per the domain:services dispatch order (#8081 comment 5269562252), this PR delivers scope items 1 and 2 only; 3/4/5 are reported on the issue, not implemented.

Item 1 — read-path scrub (delivered)

DatasourceAdminService.getDatasource() returned the driver config verbatim (datasource-admin-service.ts:199) while :179 carried a doc comment promising "with the credential stripped" and describing config as "non-sensitive — credentials live in sys_secret, never in config". Nothing stripped anything.

The comment was not merely stale, it was load-bearing — it is why the gap survived a 26-surface credential survey. It is rewritten to say what the code does, and to record what it used to claim.

What is redacted, and where the list comes from. The refused-key set is derived from each driver's own contract rather than retyped: #8078 spells a refused inline credential as z.never(), so the schema is the list, and a credential key refused tomorrow is covered the day it lands. Three sources feed the scrub:

source	keys	why
derived (z.never())	password (postgres/mysql/mongodb), authToken (turso)	#8078's own refusal shape
pre-#8078 aliases	passwd pwd token jwt auth_token authtoken	a stored row never met the parse that renamed them — the wizard persists through metadata.register
still-writable but credential-shaped	turso encryptionKey	AES-256 key the binder has no slot for; redacting on read neither grants nor removes that slot

A driver the platform ships no contract for still has the canonical spellings hidden by name. Declining to refuse an unrecognised key is a boundary choice about authoring; serving a key literally named password back in cleartext is a leak under any boundary.

URL-embedded credentials — the explicit reading the dispatch asked for. A postgresql://user:pass@host/db in config.url carries the same secret as config.password. Measured on origin/main, getDatasource() served both for the same row. A scrub stopping at config.password would have been half a scrub — the same "claims a protection it does not perform" shape this card exists to end. So the read path redacts the password component of the userinfo and leaves scheme, username and everything from the host onward byte-for-byte.

⛔ Nothing here refuses a URL, at any door. #7990 left that unruled and #8078 pinned the acceptance as a FACT; a pin guards that boundary and passes on both sides. Redacting a value on the way out is a different act from refusing it on the way in, and only the second one is unruled.

The response names what it withheld — redactedConfigKeys, the same courtesy hasSecret already pays for the bound handle.

Why the scrub needed an inverse. The edit form reads this config and patches it straight back, so a scrub with no inverse turns every untouched "Save" into silent credential deletion — trading a disclosure bug for a data-loss bug. updateDatasource therefore carries the hidden material forward on a same-driver round-trip, after the validation gate: the gate judges what the author wrote, and this is material the author never saw and is not asking to change. Same rule the credentialsRef beside it has always followed.

That also repairs a regression #8078 introduced, measured here for the first time: on main the form was served config.password verbatim, posted it back unchanged, and the write gate refused it — so editing any legacy datasource through the wizard answered 400 for a value the server itself had just supplied, including the active: false that takes a misconfigured datasource out of service.

Not changed: the stored record is never mutated. Redaction is a read-path act; the connect path reads the raw record and a legacy datasource keeps authenticating exactly as before. Getting cleartext out of the store is item 3's migration and is deliberately not attempted.

Item 2 — write-door measurement (measured; nothing to fix)

Measured end-to-end against the real HonoHttpServer, not reasoned from source:

door	legacy inline payload	reading
POST /api/v1/datasources (wizard)	config.password	400 DATASOURCE_ADMIN_ERROR, full guidance in error.message
POST /api/v1/datasources	alias passwd	400 DATASOURCE_ADMIN_ERROR, guidance + unrecognised-key prose
PATCH /api/v1/datasources/:name	config.password	400 DATASOURCE_ADMIN_ERROR, full guidance
PUT /meta	config.password	422 INVALID_METADATA + structured issues[] carrying the same message
datasource-admin plugin (service call)	config.password	throws with the full guidance; it is the object the routes wrap

No door collapses into a generic 500. The refusal guidance — naming both the secret binder and external.credentialsRef — reaches the caller intact at every door. Both codes are already ADR-0112-registered (DATASOURCE_ADMIN_ERROR, INVALID_METADATA), so no envelope change was needed and none was made. The card's worry did not materialise; that is the finding.

Reverse verification

9 of 21 pins fail on origin/main, each naming the defect it carries; 21/21 pass here. Method: the service file was reverted to origin/main's version in-tree and the suite re-run, so the readings are measured, not asserted.

Red on main: cleartext password served · URL credential served · redactedConfigKeys absent · turso authToken/encryptionKey served · alias spellings served · served-vs-stored split · round-trip 400 · non-credential edit blocked · driver change.

Green on both sides, by design: #8078's parse refusal still fires with its guidance intact (guards the spec half) · a URL-embedded credential is still ACCEPTED at the write door (guards the unruled boundary).

One pin was rewritten mid-task because it passed vacuously on both sides — "the stored record is untouched" is green on main for the worst possible reason (nothing redacts there, so served and stored are identical). It now asserts the served and stored halves together, which makes it red on main. That is the #7801 failure mode, caught here.

Gates

• check:test-source-alias — OK, 72 packages scanned. New test file; no new workspace dependency, no KNOWN_UNALIASED_TEST_IMPORTS edit.
• check:type-check-coverage — OK, 64/77 packages type-checked. service-datasource is type-checked, not ledgered; tsc --noEmit clean.
• check:type-check-debt --re-measure — OK on the built closure, 1966 raw errors, none above its recorded number. (The surplus notices are pre-existing entries below their ceiling, untouched by this PR.)
• service-datasource suite: 361/361.
• Changeset present. Untouched: content/docs/releases/**, docs/adr/**, .claude/skills/**, skills/**, sys-session.object.ts, packages/spec/src/**.

Reported on the issue, NOT implemented here

Items 3 (migration story), 4 (turso encryptionKey) and 5 (managed credential slot) are decisions belonging to other seats. Two findings from measuring them are load-bearing and are written up on #8081:

• Item 5 is REAL, not theoretical — and it is the default wizard path.
• A residual leak this PR does not close: GET /api/v1/meta/datasources still serves the same stored cleartext. Fixing it leaves the services lane ⇒ STOP and report, per the dispatch order.
• Item 4 is worse than the card states: the bound secret never reaches turso at all, so authToken — not just encryptionKey — has no working supported path post-feat(spec)!: refuse inline credentials at publish — driver config + connector authoring door (#7990, spec half) #8078.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 12, 2026 5:03pm

[github-actions]

📓 Docs Drift Check

No hand-written docs reference the 1 changed package(s). ✅