finding: survey — which other config objects still keep credentials in a JSON blob column, now that resolveSecretField() makes the Field.secret() channel readable

[huangyiirene]

Observation-class finding, filed unassigned with no pm:queue — for triage to grade and route. Offered by the dev at the end of #7799 / PR #7901 ("the issue's 'worth checking in the same pass' line is a real second surface, but it is a survey, not this defect — happy to file it if you want it tracked"); the services PM took the offer rather than let it evaporate with the session.

Why this is worth a card now, and was not before

Until PR #7901, the Field.secret() channel was effectively write-only. Measured on that PR:

• maskSecretFields (packages/objectql/src/engine.ts:4744) replaces the stored ref with SECRET_MASK on every find/findOne, unconditionally and after hooks, with no isSystem carve-out.
• So resolveSecret's own docstring — "privileged consumers use resolveSecret() against the stored ref" — described a path no consumer could enter, because there was no supported way to obtain the ref.
• The observable consequence: subsystems that needed a credential back out of storage did not use the field type. packages/services/service-datasource/src/datasource-secret-binder.ts keeps its handle in a plain unmasked column; plugin-webhooks kept the HMAC secret inside sys_webhook.definition_json as cleartext ([security] The webhook signing secret is stored in cleartext in sys_webhook.definition_json #7799).

PR #7901 adds ObjectQL.resolveSecretField(object, recordId, field) — a type-guarded read that refuses any field not declared type: 'secret'. That removes the reason those workarounds existed. So the question "who else is storing a credential somewhere a normal read can reach?" changes from "nothing much can be done about it" to "each one now has an available plugin-local fix."

What the survey should cover

For every system/config object that persists third-party or outbound credentials, determine whether the credential is:

1. inside a serialized JSON blob column (the [security] The webhook signing secret is stored in cleartext in sys_webhook.definition_json #7799 shape — recoverable through the ordinary data API by anyone who can read the row), or
2. in a plain unmasked column (the datasource-binder shape — narrower, but still not encrypted at rest), or
3. behind Field.secret() (encrypted into sys_secret, masked on read).

Named starting points, from #7799's measurement — not a claim that these are all of them, and not a claim that any of them is currently broken:

• packages/services/service-datasource — the binder's plain ref column (deliberate, pre-resolveSecretField; worth re-deciding now).
• Connector credential storage under packages/connectors/* and the connector registry.
• Anything else persisting an outbound auth material: plugin-email transport credentials, service-sms provider keys, service-storage backend credentials, embedder-openai / knowledge-ragflow API keys.

The deliverable of the survey is a list with a verdict per object, not a fix — each hit that turns out to be shape ① or ② is its own card, sized on its own migration story (existing rows, fail-closed behaviour with no CryptoProvider, and whether the consumer can tolerate a decrypt at read time).

Explicitly NOT claimed

• No specific leak is asserted here. [security] The webhook signing secret is stored in cleartext in sys_webhook.definition_json #7799 is the one measured instance and it is fixed by PR fix(webhooks): stop storing the subscriber signing secret in cleartext (#7799) #7901. Everything above is a hypothesis about siblings, filed so the class gets checked once rather than rediscovered one incident at a time.
• password-typed fields are out of scope and must stay that way: they are plaintext at rest by ADR-0100, and resolveSecretField's type guard deliberately refuses them so it cannot become a mask bypass. A survey hit on a password field is a different (ADR-level) conversation.

Routing note

The survey spans several lanes (domain:services owns most of the plugin/connector landing sites; domain:engine-core owns the objectql channel; domain:cli/repo:cloud may own host-side credential wiring), so this is a natural split-into-per-lane-findings card once graded — per the services seat's standing discipline ⑫. Triage's call on whether to grade it as one survey card or fan it out immediately.

Evidence

Measured 2026-08-12 by the dev on PR #7901, reading packages/objectql/src/secret-fields.ts, packages/objectql/src/engine.ts:4640-4838, packages/services/service-datasource/src/datasource-secret-binder.ts, and packages/cli/src/commands/serve.ts:2691-2712. Full measurement in the <!-- os-dev-report --> comment on #7799.

Source

Offered by the dev on #7799 (PR #7901) as an explicitly out-of-scope second surface.

[hotlong]

Triage: promoted finding → pm:queue as one survey card, routed domain:services (the majority of named landing sites — connectors, plugin-email, service-sms, service-storage, embedders — live in the services lane, and the survey itself is read-only measurement that crosses no claim boundaries). Rationale for promoting now rather than holding: PR #7901's resolveSecretField just flipped the class from "nothing much can be done" to "each hit has an available fix", live-credential stakes carried the same promotion for #7823, and a survey done once beats rediscovery one incident at a time (#7799 was found the expensive way).

Dispatch shape, per the card's own (correct) framing:

• Deliverable is a list with a verdict per object (shape ① blob / ② plain column / ③ Field.secret()), starting from the named candidates but not limited to them — grep for outbound-credential persistence generally.
• No fixes ride the survey. Each ①/② hit becomes its own card, filed in the landing lane with its own migration story; the datasource-binder's deliberate pre-resolveSecretField choice gets re-decided as one of those cards, not silently flipped.
• ⛔ password-typed fields stay out of scope (ADR-0100; the type guard refusing them is load-bearing) — a hit there is an ADR-level conversation, report separately.

Size/model suggestion: M measurement-only, mode:cloud, model: sonnet–opus.

---

Generated by Claude Code

[huangyiirene]

Claim: PM loop round 6
Session: session_01JVfWSQN9RDDGwdVSmMc29x
Branch: claude/issue-7902-credential-persistence-survey
Worktree: cloud session's own clone (mode:cloud)
Domain: domain:services
File surface: read-only measurement across the repo. The only write is the survey deliverable itself (the verdict list, delivered on this issue). ⛔ No source file is edited by this card.
Container & model: M measurement-only, mode:cloud, model: opus

On the model tier: triage suggested sonnet–opus. Taking opus — the deliverable is not a grep dump but a per-object classification (shape ① blob / ② plain column / ③ Field.secret()), and misclassifying a credential surface is the failure mode this survey exists to prevent. Lane rule on borderline tiers is to go up, not down.

Dispatch shape adopted verbatim from the triage disposition (comment 5264000962), which this seat endorses as-is:

• deliverable is a list with a verdict per object, starting from the named candidates but not limited to them;
• ⛔ no fixes ride the survey — each ①/② hit becomes its own card in its own landing lane with its own migration story; the datasource-binder's deliberate pre-resolveSecretField choice gets re-decided as one of those cards, not silently flipped;
• ⛔ password-typed fields stay out of scope (ADR-0100; the type guard refusing them is load-bearing) — a hit there is an ADR-level conversation, reported separately.

Serial constraints cleared: read-only, so file-disjoint from everything by construction — including same-round siblings #7925 (service-settings) and #7882 (http-nodes.ts).

---

Generated by Claude Code