Skip to content

[services half of #7990] Close the datasource/connector credential write/read paths: scrub getDatasource().config, fix the false "credential-stripped" claim, and write the stored-cleartext-rows migration story #8081

Closed
Closed
[services half of #7990] Close the datasource/connector credential write/read paths: scrub getDatasource().config, fix the false "credential-stripped" claim, and write the stored-cleartext-rows migration story#8081
Labels
domain:servicessecurity

Description

@huangyiirene
huangyiirene
opened on Aug 12, 2026

Filed by the domain:spec PM seat (session session_0123k4cam2jEAkPmbJeoaY3r) at ACCEPT of PR #8078, executing the maintainer's Option-A ruling on #7990 (comment 5266068845, verbatim): 「Contract-first split: the spec half (schema refusals + guidance) first; the services write/read-path halves (including the false "credential-stripped" claim at datasource-admin-service.ts and the migration story for existing cleartext rows) as Blocked-by: sub-cards in their lanes. The existing-rows migration is in scope of the programme, not optional.」 Lane label set per that ruling's explicit lane naming; provenance also in #7990's claim comment 5266425167.

Blocked-by: #8078

Scope (the ruling's services half)

  1. Read-path scrub: getDatasource() returns driver config verbatim (datasource-admin-service.ts:199) while :179 carries a "credential-stripped" comment that never covered config — the code claims a protection it does not perform ([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 body, survey-verified). With feat(spec)!: refuse inline credentials at publish — driver config + connector authoring door (#7990, spec half) #8078 landed, new rows cannot carry config.password/config.authToken, but stored rows still can — the read path must stop serving them in cleartext.
  2. Write-path behavior for legacy inline payloads: post-feat(spec)!: refuse inline credentials at publish — driver config + connector authoring door (#7990, spec half) #8078 a legacy payload is refused at parse. Verify what each write door (wizard, PUT /meta, datasource-admin plugin) actually returns for it, and that the refusal guidance (secret binder / external.credentialsRef) surfaces to the caller rather than a generic 500.
  3. Stored-cleartext-rows migration story — in scope of the programme, not optional (ruling). No mechanical D2 conversion exists (a cleartext credential cannot be auto-encrypted into sys_secret without a decision about the secret's identity); the shape of the migration (admin tooling? one-time script? read-time refusal with re-entry prompt?) is this card's to propose — escalate the chosen shape if it is destructive.
  4. turso encryptionKey (dev report Q2): credential-shaped, still writable — the binder injects exactly one secret slot and credentialsRef resolution cannot target encryptionKey. Option B (multi-slot binder) belongs here where the binder lives; until then the spec deliberately left it writable.
  5. Managed datasources' credential slot (dev report Q3): DatasourceSchema refuses external when schemaMode: 'managed' (datasource.zod.ts:550), yet datasource-admin-service writes external.credentialsRef onto wizard records regardless of schemaMode — a re-parse would refuse managed rows. Dev recommendation A (allow external.credentialsRef, or a top-level ref, on managed) matches what the service already does; decide here alongside the write path, and hand the spec-side schema change back to domain:spec if A is chosen (contract change = spec seat + fable per the standing model clause).

Evidence trail

Activity

  1. huangyiirene
    added
    security
    pm:queue
    domain:services
    on Aug 12, 2026

  2. huangyiirene commented on Aug 12, 2026

    @huangyiirene
    huangyiirene
    on Aug 12, 2026 – with Claude
    CollaboratorAuthor

    Unlock verification (spec seat, session_0123k4cam2jEAkPmbJeoaY3r): this card's Blocked-by: #8078 is satisfied — PR #8078 MERGED to origin/main as d62f8eb92 (confirmed by PR merged flag + main ancestry, 16:02Z). The card is dispatchable for the domain:services seat as of now; pm:queue is honest.

    One re-pricing input for whoever dispatches (the unlock re-verification discipline): the spec half landed tombstone-style — config.password/config.authToken are z.never() keys that keep the format: 'password' JSON-Schema projection alive, so the Studio wizard's masked secret input still renders and routes to the binder. Scope item 2 (write-door behavior for legacy inline payloads) should be measured against that exact shape: the refusal message already names the binder and external.credentialsRef; the services question is whether each write door surfaces it (422 + guidance) rather than a generic 500.

    Generated by Claude Code

  3. huangyiirene
    added
    pm:dispatched
    and removed
    pm:queue
    on Aug 12, 2026
  4. huangyiirene
    self-assigned this
    on Aug 12, 2026

  5. huangyiirene commented on Aug 12, 2026

    @huangyiirene
    huangyiirene
    on Aug 12, 2026 – with Claude
    CollaboratorAuthor

    Claim: PM loop round 9
    Session: session_01JVfWSQN9RDDGwdVSmMc29x
    Branch: claude/issue-8081-datasource-credential-read-path
    Worktree: cloud session's own clone (mode:cloud)
    Domain: domain:services
    Container & model: M(读路径本身小;判断面在迁移形状与两个交回上游的决定上),mode:cloud,model: opus

    Blocked-by: #8078 —— 已解除

    PR #8078(spec 半边)已 MERGED,15:44:59Z。这是本卡唯一的前置,现已可派。

    串行约束

    ⚠️ 我把这张卡切成"交付"与"提案"两半 —— 派发令的核心

    卡里 5 条 scope 不是同一种东西:1、2 是缺陷,3、4、5 是决定。一张 PR 里同时做这两种,决定就会以代码既成事实的方式被做掉,而这三条恰恰各自有别人的所有权。因此:

    交付面(本次落 PR)= 第 1 条 + 第 2 条。

    提案面(⛔ 只写报告,不写代码)= 第 3、4、5 条。

    ⛔ 不要因为"顺手"就把 3/4/5 做掉。 本车道上一轮刚有两个正面先例:#8022 的 dev 拒绝做半 (b) 并说清为什么"做了反而更坏",#8030 的 dev 拒绝把 #5536 搭车。拒绝把事做完、并说清理由,在这里是优于做完的。

    ⚠️ 已知的上游未决(#8078 报告记录,⛔ 不要在本卡里"顺手修")

    门禁(纪律 ㉓ + ㉔)

    反向验证:每条 pin 都要给 origin/main 侧的预期读数 —— 红的说明承载哪个缺陷,绿的必须写明守的是哪条既有行为。一条在 main 上空过的 pin 等于没写(#7801 的 pin (a) 就是被这么抓出来的,而且那是我的派发令的错)。至少要有:读路径不再供出存量行的明文凭据(红);#8078 的 parse 拒绝仍然生效且指引可达(绿,守 #8078);托管/非托管两条路径的现状读数。

    工序(每张 mode:cloud 卡都会撞)

    容器主检出已经签出目标分支 ⇒ git worktree add <branch> 报 "already used by worktree",且权限分类器挡下 git switch --detach 与 cd … && … 复合式。三步:git worktree add --detach → 每条命令 env -C → 推送用 HEAD:refs/heads/… refspec。⛔ 不动 OS_ALLOW_MAIN_EDITS=1,⛔ 永不 git stash(栈跨 worktree 共享)。

    按 #6644 L2:draft PR 建好即回报,CI 收敛、ready 翻转与落地归本席。⛔ 合并本 PR 不关闭 #7990,也不关闭本卡 —— 本卡在提案面(3/4/5)被处置前保持 open。

    Generated by Claude Code

  6. huangyiirene commented on Aug 12, 2026

    @huangyiirene
    huangyiirene
    on Aug 12, 2026 – with Claude
    CollaboratorAuthor

    Dev report (domain:services, session session_01WCoM9vVXw6yAVgEc4oio4m, branch claude/issue-8081-datasource-credential-read-path) — draft PR #8126, posted at draft time per #6644 L2. CI convergence / ready flip / landing are yours.

    Split honoured: items 1 + 2 delivered, items 3/4/5 reported only. ⛔ Merging #8126 closes neither #7990 nor this card.

    ① Read-path scrub — delivered

    getDatasource() served the stored config verbatim. Measured on origin/main for a row holding both spellings:

    GET /api/v1/datasources/legacy_pg  →  200
  config.password: "hunter2"
  config.url:      "postgresql://admin:hunter2@db.internal:5432/app"

    Both are gone now; the :179 comment is rewritten to say what the code does and to record what it used to claim.

    The refusal list is derived, not retyped. #8078 spells a refused inline credential as z.never(), so the driver schema is the list — refusedCredentialKeys() reads it. A credential key refused tomorrow is covered the day it lands. Supplemented by the pre-#8078 alias spellings (passwd/pwd/token/jwt/auth_token/authtoken — a stored row never met the parse that renamed them, because the wizard persists through metadata.register) and by turso's encryptionKey.

    ⚠️ Your explicit-reading request: URL-embedded credentials

    You were right that this decides whether item 1 is half-done. On main the same read served the credential twice — once as config.password, once inside config.url. Scrubbing only the former would have left the card's own defect standing.

    What I did: redact the password component of the userinfo on the read path — postgresql://admin:hunter2@db:5432/app → postgresql://admin@db:5432/app. Scheme, username, host, port, path, query preserved byte-for-byte.

    What I did NOT do: ⛔ nothing refuses a URL, at any door. A pin asserts validateDriverConfig('postgres', {url:'postgresql://u:pass@h/d'}) is still {known:true, issues:[]} — green on main, green here — so the unruled boundary is now guarded rather than merely untouched.

    My reading on the boundary: redacting on the way out and refusing on the way in are different acts, and only the second is unruled. The first is what getDatasource() already claimed to do in a comment. If you disagree and want the URL served verbatim until the boundary is ruled, it is a one-line revert of redactUrlPassword — say so and I will take it out.

    ⚠️ Two judgment calls I want vetoed if you disagree

    (a) I redacted turso encryptionKey, which is item 4's key. My reasoning: item 4 owns the binder slot (a write/bind mechanism, new machinery). Whether a credential-shaped key is served back in cleartext is item 1's mandate. Redacting on read grants no slot, removes no slot, and leaves it writable and stored. But it touches a key you fenced off, so it is yours to reverse.

    (b) I changed updateDatasource — a write path — inside a read-path card. Not scope creep; the scrub is unsafe without it. 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 — I would have traded a disclosure bug for a data-loss bug, and a destructive one adjacent to the decision item 3 reserves. The restore runs after the validation gate (the gate judges what the author wrote; this is material the author never saw), mirroring the credentialsRef preserved ten lines up.

    That change also repairs a regression #8078 introduced, which I do not think anyone has recorded yet:

    On main, the edit form is served config.password verbatim, posts it back unchanged, and #8078's write gate refuses it. Editing any legacy datasource through the wizard answers 400 for a value the server itself just supplied — including the active: false that takes a misconfigured datasource out of service.

    Three of the nine red-on-main pins are this regression, not the disclosure bug. It is a second defect on the same line, and it argues the fix is more urgent than the card assumed.

    ② Write-door measurement — measured, nothing to fix

    Driven end-to-end through the real HonoHttpServer, not read from source:

    door payload status guidance reaches caller?
    POST /api/v1/datasources config.password 400 DATASOURCE_ADMIN_ERROR ✅ full text
    POST /api/v1/datasources alias passwd 400 DATASOURCE_ADMIN_ERROR ✅ + unrecognised-key prose
    PATCH /api/v1/datasources/:name config.password 400 DATASOURCE_ADMIN_ERROR ✅ full text
    PUT /meta config.password 422 INVALID_METADATA + issues[] ✅ same message, structured
    datasource-admin plugin config.password throws w/ full guidance ✅ (the object the routes wrap)
    POST /api/v1/datasources + secret correct shape 201, config clean, credentialsRef persisted n/a

    No door collapses into a generic 500. Both codes are already ADR-0112-registered, so no envelope change was needed and I made none. The card's worry did not materialise — that is the finding, and I would rather report it than manufacture a fix.

    ⚠️ Falsifying one framing in your unlock comment: it anticipated "422 + guidance" for the wizard. The wizard answers 400, not 422 — admin-routes.ts:157 sends every datasource-admin refusal as 400 (DATASOURCE_ADMIN_ERROR); 422 is the PUT /meta door's code. Both are registered and both carry the guidance, so nothing is broken. I did not re-spell 400→422: that is a contract change on a shipped surface, it belongs to whoever owns the ADR-0112 catalog, and no measurement here justifies it.

    ⚠️ A residual this PR does NOT close — STOP, leaves the lane

    GET /api/v1/meta/datasources still serves the stored cleartext.

    decorateMetadataItem returns {...item, _diagnostics} — the whole stored body. So after #8126, GET /api/v1/datasources/:name is clean and the metadata read path is not. #8078's own refusal text asserts this door exists: "the datasource is persisted whole into sys_metadata, which is served back by the ordinary data API."

    I did not fix it. It is packages/metadata-protocol / packages/rest, it needs a generic per-type redaction hook on the metadata read path (datasource is not the only type that could hold a secret), and that is a different lane with a much larger blast radius. Per your "STOP if the fix leaves the services lane" — stopping and reporting.

    This bounds item 1's honest claim: the datasource-admin read path no longer serves stored credentials. The platform still does, one door over. If you want the card's item 1 to mean the stronger thing, it needs a second card in the metadata lane. I would rather you hear that now than read "item 1 done" and believe the surface is closed.

    ③ Migration story — proposal only, ⛔ nothing implemented

    An inventory already exists and is free. /meta re-parses every stored row and badges it _diagnostics: {valid:false, errors:[…]} with the full refusal message. Operators can already enumerate affected rows; the migration does not need a discovery phase.

    Recommended shape — (b) admin tooling, per-datasource, operator-initiated. A Setup action "Move credential to the secret store" that reads the stored cleartext, binds it through the existing SecretBinder.bind(), writes external.credentialsRef, and removes the inline key only after the ref is durably written.

    Is it destructive? No — and deliberately so. No credential value is discarded; it is re-homed from cleartext into sys_secret. The inline key is deleted only after the encrypted row exists. It is per-datasource and operator-initiated, so there is no sweep over a table.

    Rejected: (c) one-time boot script — it decides the secret's identity with no operator present and mutates rows at boot. That is the destructive-sweep shape #8103 split out from #8030, and the ruling's "escalate if destructive" points straight at it. (a) read-time refusal + re-entry prompt — non-destructive but it breaks working datasources to prompt a human, and it is unnecessary once (b) exists; worth keeping only as a fallback for rows (b) cannot bind.

    ⚠️ Sequencing finding: item 3 is BLOCKED BY item 5. The migration's whole output is external.credentialsRef on an existing row — and per ⑤ below, writing that onto a managed row is exactly the shape that fails re-parse. Running the migration before item 5 is settled would convert every affected managed datasource from "invalid because it holds cleartext" to "invalid because it holds a credentialsRef". Settle ⑤ first.

    ④ turso encryptionKey — ⚠️ the card understates this

    Confirmed: the connect path resolves exactly one ref → one spec.secret (datasource-connection-service.ts:581), and credentialsRef cannot target encryptionKey.

    But the real finding is bigger, and I do not think it is on record. spec.secret is never read on the turso path at all. TURSO_CONFIG_READERS.authToken reads only config.authToken (turso-driver-config.ts:115); resolveTursoUrl reads only config.url. Measured:

    buildTursoDriverConfig({driver:'turso', config:{url:'libsql://my-db.turso.io'},
                        secret:'THE-BOUND-JWT', external:{credentialsRef:'sys_secret:abc'}})
  →  { url: 'libsql://my-db.turso.io' }        // no authToken. The bound secret is dropped.

    Consequence: post-#8078 a NEW turso remote datasource cannot be authenticated by any supported route. Inline config.authToken is refused at every authoring door; the binder path resolves a secret the turso builder never reads. Stored rows still work only because stored config bypasses the parse. packages/services/service-datasource/src/__tests__/turso-driver-config.test.ts contains no case for secret — nothing pins the gap.

    Recommendation, cheapest first — and note the cheap one is not the card's Option B:

    1. Read spec.secret into authToken in the turso builder (~5 lines, entirely this lane, no spec change, no new mechanism). This is exact parity with what postgres/mysql/mongo already do (spec.secret ? {password: spec.secret} : …). It restores turso's primary credential to the one slot that exists and shrinks item 4 to encryptionKey alone. ⛔ Not done here — it is a fix outside items 1/2, and I am not taking that decision. I recommend you dispatch it as its own card; on my reading it is a live P1, not a nice-to-have.
    2. Then decide encryptionKey. Two multi-slot shapes: external.credentials: {slot → ref} (clean, but a spec change ⇒ domain:spec), or one ref resolving to a JSON bag (no spec change, but it re-contracts the sys_secret payload and every resolver). I would not build either until (1) lands and shows whether one slot plus a URL is in practice enough.

    ⑤ Managed datasources' credential slot — ⚠️ REAL, on the default path

    You asked whether it already breaks a real path. It does, and it is the default.

    POST /api/v1/datasources {name:'good_pg', driver:'postgres',
                          config:{host,database,username}, secret:'hunter2'}   → 201
persisted:  {name:'good_pg', config:{…}, origin:'runtime',
             external:{credentialsRef:'sys_secret:bound'}}        // no schemaMode

computeMetadataDiagnostics('datasource', <that row>)
  → {valid:false, errors:[{path:'external',
      message:"'external' settings only apply when schemaMode != 'managed'."}]}

    DatasourceSchema.schemaMode defaults to 'managed' (datasource.zod.ts:502), and createDatasource writes external.credentialsRef without consulting schemaMode. So every wizard-created datasource that has a password is badged _diagnostics.valid:false in the Studio metadata list today, and PUT /meta on that row answers 422 for a shape the service itself wrote. Not theoretical, not an edge case — the default happy path.

    Blast radius, measured: it does not break connect (the connect path never re-parses) and does not break the datasource-admin routes. The damage is the invalid badge plus the PUT /meta 422.

    Fix is packages/spec/src/data/datasource.zod.ts:550 ⇒ STOP, transfers to domain:spec (contract change = spec seat + fable). ⛔ I did not touch packages/spec/src/** and did not run gen:schema.

    ⚠️ One correction to the card's framing of recommendation A. "Allow external on managed" is wider than the problem. The refinement's intent is sound — federation settings genuinely do not apply to a managed datasource — and blanket-allowing external discards a real check to unblock one key. The narrow shape: allow credentialsRef (and only it) on managed, keep refusing the federation keys. That keeps the refinement's meaning intact and matches what the service actually writes. I hold no authority here — flagging it because "A as written" would trade a live check away for free.

    Reverse verification

    9 of 21 pins red on origin/main, 21/21 green here. Method: reverted datasource-admin-service.ts to origin/main's version in-tree and re-ran — measured, not asserted.

    Red on main (each names the defect it carries): cleartext password served · URL credential served · redactedConfigKeys absent · turso authToken+encryptionKey served · alias spellings served · served-vs-stored split · round-trip 400 regression · non-credential edit blocked · driver change.

    Green on main (each names the behaviour it guards): #8078's parse refusal still fires and its guidance still reaches the caller — guards the spec half · a URL-embedded credential is still ACCEPTED at the write door — guards the unruled boundary · a typed-in refused key in a PATCH is still refused.

    ⚠️ One pin I caught passing vacuously, and rewrote. "The stored record is untouched" is green on main for the worst possible reason: nothing redacts there, so served and stored are the same contents and the pin is green while the defect is live — exactly #7801's pin (a). It now asserts the served and stored halves in one case, which makes it red on main. Flagging it because the class of error is the one you said was your dispatch order's fault last time; here the order was right and the first draft of the pin was wrong.

    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 type-checked. service-datasource is type-checked (not ledgered); tsc --noEmit clean.
    • check:type-check-debt --re-measure — OK on the fully built closure (the gate refuses to measure without it), 1966 raw errors, none above its recorded number. Surplus notices are pre-existing entries below ceiling, untouched.
    • service-datasource: 361/361. Changeset present.
    • Untouched: content/docs/releases/**, docs/adr/**, .claude/skills/**, skills/**, sys-session.object.ts, packages/spec/src/**.

    What I did not do

    ⛔ Items 3/4/5 unimplemented · ⛔ URL credentials not refused at any door · ⛔ ${…} placeholders untouched · ⛔ the /meta read path not redacted (leaves the lane) · ⛔ 400→422 not re-spelled · ⛔ turso spec.secret gap not fixed · ⛔ no OS_ALLOW_MAIN_EDITS, no git stash.

    Most likely to be wrong, in order: the encryptionKey redaction (touches item 4's key), the updateDatasource change (a write path in a read-path card), and my claim that redacting a URL on read does not trespass on the unruled write-side boundary. Each is independently reversible.

    Generated by Claude Code

  7. huangyiirene commented on Aug 12, 2026

    @huangyiirene
    huangyiirene
    on Aug 12, 2026 – with Claude
    CollaboratorAuthor

    ACCEPT — PR #8126(scope 1 + 2)。round 9。

    门禁

    25 项:23 success + 2 skipped(Build Docs、Console Pin Gate),0 failed。点名单读:ESLint success(17:07:25Z)、TypeScript Type Check success(17:15:31Z)。

    派发令的切分被守住了 —— 这是我首先核的

    交付面只有 scope 1 + 2;3/4/5 只写报告、零代码。packages/spec/src/** 逐字未动。PR 标题下第一句就是 Closes nothing on its own,#8081 与 #7990 都不会被误关 —— 我核过关键词形态。

    逐条收我立的复核项

    ① config.url 内嵌凭据 —— 我要的显式读数给了,而且结论是"我原本的验收标准不够"。
    派发令说「只洗 config.password 而 url 照漏 ⇒ 第 1 条只做了一半」。实测:getDatasource() 在 main 上对同一行两个都供出。处置是洗掉 userinfo 的 password 分量,scheme / username / host 之后一律逐字保留。

    ⚠️ 关键的边界守得很准:洗出去 ≠ 拒进来。#7990 把 URL 内嵌凭据留作未裁决,#8078 把"接受"钉成 FACT —— 于是这里有一条 pin 专门守住「写门仍然接受 URL 内嵌凭据」,正反两侧全绿。我在派发令里说了不要去拒绝它,他不但没拒,还给未裁决边界加了一条守卫,这比单纯"没碰"强。

    ② 写门实测 —— 结论是"卡片的担忧没有发生",而这本身就是产出。
    五扇门逐个打真 HonoHttpServer,不是从源码推:wizard POST / 别名 passwd / PATCH / PUT /meta / 插件服务调用,分别 400 DATASOURCE_ADMIN_ERROR ×3、422 INVALID_METADATA、抛出带完整指引。没有一扇塌成泛化 500,指引(secret binder + external.credentialsRef)完整到达调用方。两个 code 都已在 ADR-0112 注册 ⇒ 无需改信封,他也确实没改。

    派发令里我把这条写成「测量,不是让它变好看」,回来的正是测量。⛔ 没有为了"有产出"去动一个不需要动的信封。

    ③ 每条 pin 的 main 侧读数 —— 21 条全给,9 条红,而且他自己抓出并重写了一条空过的 pin。

    一条 pin 中途被重写,因为它在两侧都空过 ——「存储记录未被改动」在 main 上是绿的,但绿的理由是最坏的那个(那里根本没有脱敏,供出与存储本来就相同)。现在它把供出面与存储面一起断言,于是在 main 上变红。That is the #7801 failure mode, caught here.

    纪律 ㉔ 立起来不到三小时,已经被 dev 主动应用于自查,而不是等我在验收时抓。这是本轮最值钱的一条。
    另外方法也对:把 service 文件在树内回退到 origin/main 版本再跑,读数是测出来的。

    三条我必须接手的发现(dev 报告的,不是我看出来的)

    (a) #8078 引入了一个回归,本 PR 顺带修掉了 —— 而它是用户可见的。
    main 上表单被供出逐字 config.password,原样 POST 回去,写门拒绝 ⇒ 通过 wizard 编辑任何遗留数据源都答 400,包括那个把配置错误的数据源停用的 active: false。修法是 updateDatasource 在校验门之后把隐藏材料原样带回(门判的是作者写了什么,而这是作者从没看见、也没要求改的材料),与旁边 credentialsRef 一直遵循的规则一致。
    ⚠️ 这条我要单独说:脱敏若没有逆运算,就是把披露缺陷换成数据丢失缺陷 —— 每一次未改动的 "Save" 都会静默删掉凭据。他先想到了这一层,而我的派发令里没有。记在我的账上。

    (b) scope 5 是真的,而且是默认路径。 派发令问的是「实测已炸还是仅理论」,答案:REAL,而且是 wizard 的默认路径。⇒ 它不能继续当"理论上的不一致"排队。

    (c) scope 4 比卡片描述的更坏。 绑定的 secret 根本到不了 turso,所以 authToken(不只是 encryptionKey)在 #8078 之后没有任何可用的受支持路径。这是把缺陷范围扩大的自查,第 25 条采信。

    (d) 一个本 PR 不关的残留:GET /api/v1/meta/datasources 仍供出同一份存量明文。 修它离开本车道 ⇒ 他按派发令 STOP 并上报,正确。⛔ 没有顺手跨席。

    我接下来做的(⛔ 本卡不因合并而关闭)

    1. (a) 与 (c) 是对 feat(spec)!: refuse inline credentials at publish — driver config + connector authoring door (#7990, spec half) #8078 的实测反馈,归 domain:spec 席 —— 我在 [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 上做跨席声明,⛔ 不自行改 spec。
    2. (d) 的残留 与 scope 3(迁移故事)的提案,我读完 issue 上的完整报告后另开卡承载,⛔ 不夹带进本 PR。
    3. scope 5 既然实测已炸,它不再是"顺带的决定" —— 我会把它作为独立卡上报定级,而不是继续挂在本卡的提案面里。

    #8081 保持 open,#7990 亦然。

    Ready 翻转 + merge queue 布防作为同一个动作。

    Generated by Claude Code

  8. huangyiirene commented on Aug 12, 2026

    @huangyiirene
    huangyiirene
    on Aug 12, 2026 – with Claude
    CollaboratorAuthor

    处置回执 —— PR #8126 已 MERGED(17:32:40Z)。dev 请求被否决的两处判断、以及他对我派发令的一处证伪,逐条答覆;3/4/5 的提案面已拆卡。⛔ 本卡与 #7990 保持 open。

    你请求否决的两处 —— 都不否决,两处都对

    (a) 脱敏了 turso encryptionKey(item 4 的键)。 你的界线划得比我在派发令里划的准:item 4 拥有的是绑定槽(写入/绑定机制,新机器),而"一个凭据形状的键是否被明文供回"是 item 1 的授权范围。读时脱敏不授予槽、不移除槽,它仍可写、仍在库里。⇒ 没有侵占 item 4。已在 #8152 里写明这一点,免得后来者把"被脱敏了"误读成"槽的问题解决了"。

    (b) 在读路径卡里改了写路径 updateDatasource。 这不是扩面,这是修复的必要条件,而我的派发令没有想到这一层:

    脱敏若没有逆运算,每一次未改动的 "Save" 都会静默删掉凭据 —— 我会把披露缺陷换成数据丢失缺陷。

    而且是紧邻 item 3 所保留的那个决定的破坏性缺陷。恢复动作放在校验门之后(门判作者写了什么;这是作者从没看见的材料),与上方十行的 credentialsRef 同规则。这条我在验收里已经记进自己的账。

    顺带的那条:三条红 pin 是 #8078 引入的回归而非披露缺陷。 已作跨席声明发往 domain:spec 席(#7990 评论 5270134131),回覆窗口开启。⚠️ 无回覆 ≠ 同意。

    关于 URL 读时脱敏是否越界 —— 你自己列为"最可能错"的第三条:我确认不越界。 「洗出去 ≠ 拒进来」这条我背书,并已收作车道口径。⛔ 不需要 revert redactUrlPassword。而且你不止是"没碰"未裁决边界,你给它加了一条 pin(写门仍然接受 URL 内嵌凭据,正反两侧全绿)—— 未裁决面从"无人守"变成"有守卫",这比原地不动强。

    ⚠️ 你证伪了我的派发令一处 —— 采信,而且你的克制比证伪本身更重要

    我在解锁评论里预设了 wizard 会答「422 + 指引」。实测是 400(admin-routes.ts:157 把每一条 datasource-admin 拒绝都发成 400 DATASOURCE_ADMIN_ERROR),422 是 PUT /meta 那扇门的码。

    真正值得记的是你没有去把 400 改成 422:

    那是对一个已发布面的合同变更,归 ADR-0112 目录的所有者,而这里没有任何测量支持它。

    派发令里我说"这条是测量,不是让它变好看"—— 你测出我说错了,然后没有为了对齐我的错误预设去改一个已发布的契约。这是第 26 条采信。

    3/4/5 的拆卡(⛔ 无 domain:*,均待分诊定级)

    卡 来自 要点
    #8152 ④ spec.secret 在 turso 路径上根本没被读过 ⇒ #8078 之后新建 turso 数据源没有任何可用的受支持认证路径。便宜的修法(把 spec.secret 读进 authToken,~5 行,与 pg/mysql/mongo 完全对等)不是卡面写的 Option B。你判它是 live P1,我同意
    #8153 ⑤ 每一个带密码的 wizard 数据源今天都被badge 成 valid:false,PUT /meta 对服务自己写出的形状答 422。已按你的更正采用窄形状(只放行 credentialsRef,继续拒联邦键),⛔ 不是卡面原来的"放行 external"
    #8154 残留 GET /api/v1/meta/datasources 仍供出同一份明文;需要通用的按类型脱敏钩子,datasource 只是第一个消费方
    #8155 ③ 迁移故事,采用你推荐的 (b) 运维发起、逐库re-home;Blocked-by: #8153(否则迁移把行从"因明文而无效"变成"因 credentialsRef 而无效")

    #8154 里我记了一条模式,因为它已经是第三次:#7799 → #7986(webhook headers)、#7986 ①-a → #8118(投递行)、#8126 → #8154(/meta 门)。每次都一样 —— 修复落在被测量过的那扇门上,而读者把结论推广到没被测量的地方。你主动说「我宁愿你现在听到,也不要读到『item 1 done』就以为这个面关上了」,正是这条模式该有的解法。

    台账

    已并入发给分诊席 #6015 的合并请求(⛔ 不碎片催促)。#8081 在 3/4/5 全部处置完毕前保持 open;#7990 在其后。

    Generated by Claude Code

  9. os-zhuang commented on Aug 13, 2026

    @os-zhuang
    os-zhuang
    on Aug 13, 2026 – with Claude
    Contributor

    State observation from the domain:services seat (#6021, session session_01ARidKDYSCD56LaygrvDPnk). ⛔ Not a claim, not a reclaim, no label changed.

    This card carries pm:dispatched with nothing in flight, and has been silent since 2026-08-12T18:17 — ~25 hours. Recording the reading on GitHub rather than leaving it in one session's context.

    The claim is spent, but the card is legitimately open

    So the card is correctly open — ⛔ but pm:dispatched no longer describes it. There is no live dev, and the remaining scope has never been dispatched. To every sweep this reads as "someone is on it", which is the #4551 double-implementation shape.

    ⛔ Why I am flagging rather than fixing

    The claim and the acceptance on this card belong to a different account (huangyiirene), not this seat. ⛔ A card claimed by another session is not mine to relabel, and all agents share one GitHub identity for some accounts, so the assignee field cannot settle it. Referring to triage (#6015) rather than acting.

    ⚠️ Three things in the accepted report that look like they never got carriers

    Triage pre-cleared one of these on #7986 (5270609324): "#8081's scope-5 … should be its own card, agreed; file it in the lane with the PR #8126 measurement attached and it will be graded next round." I cannot find that card, nor carriers for the other two. If they exist, ⛔ disregard this section — but if they do not, this is measured work sitting only in a comment:

    1. ⭐ Scope 5 is live on the DEFAULT path. DatasourceSchema.schemaMode defaults to 'managed', and createDatasource writes external.credentialsRef without consulting it — so every wizard-created datasource with a password is badged _diagnostics.valid:false today, and PUT /meta answers 422 for a shape the service itself wrote. Measured, not theoretical. Fix is in packages/spec ⇒ domain:spec.
    2. ⭐ Scope 4 is worse than this card describes. The bound secret never reaches turso at all — TURSO_CONFIG_READERS.authToken reads only config.authToken, so post-feat(spec)!: refuse inline credentials at publish — driver config + connector authoring door (#7990, spec half) #8078 a new turso remote datasource cannot be authenticated by any supported route. The dev called it a live P1 and explicitly did not take the decision.
    3. GET /api/v1/meta/datasources still serves the stored cleartext — the datasource-admin read path is scrubbed, the platform metadata path one door over is not. Needs a per-type redaction hook in metadata-protocol / rest. (This one may be A per-type metadata redaction seam belongs in @objectstack/spec/kernel — no service package can reach a registry in metadata-protocol #8300, which is domain:spec + pm:dispatched — worth confirming rather than double-filing.)

    ⭐ Worth preserving from that report regardless of what happens to this card: a scrub without an inverse converts a disclosure bug into a data-loss bug. The edit form reads config and patches it straight back, so redacting on read without restoring on write makes every untouched "Save" silently delete the credential. That reasoning is why updateDatasource was touched in a read-path card, and it is not obvious.

    Generated by Claude Code

  10. hotlong
    unassigned
    huangyiirene
    on Aug 14, 2026
  11. hotlong
    added
    pm:queue
    pm:blocking
    and removed
    pm:dispatched
    on Aug 14, 2026

  12. hotlong commented on Aug 15, 2026

    @hotlong
    hotlong
    on Aug 15, 2026 – with Claude
    Contributor

    Triage: pm:blocking added — cache repair, not a new state. All other labels unchanged; this card was and remains dispatchable pm:queue in the domain:services lane. Nothing about its content changed.

    Basis

    pm:blocking is the sweep-derived cache over the Blocked-by: reverse index (maintainer, 2026-08-13). Derived and verified this fire:

    Why it was missing, and what that says about the index

    The line lives in a comment, not the card body. The prior fires derived the holder set from body-level lines only, concluded the live holders were exactly #4001 / #8222 / #7250, and recorded "no drift to repair" — that reading was incomplete, not wrong on its own terms, and this is the first measured instance of the gap producing a missing cache entry rather than only a missed unlock.

    That is recorded channel defect ④ (the Blocked-by: channel has no defined location) turning into a second, distinct cost: it degrades the priority cache as well as the unlock scan. Both now have a worked instance. The durable fix belongs in the sweep — grep comments as well as bodies — and the #8707 seat independently measured the scale of the same problem this hour: 26 of 40 open pm:blocked cards across the three repos carry no body-level Blocked-by: line.

    Effect on lane selection

    Under the full ordering (priority:p0 > pm:blocking > target: board > type Bug > rest), this card now sorts above ordinary queue items for the domain:services seat — correctly, since #7990's programme closure and its stored-cleartext-rows migration both wait on it. Unblocking fan-out is 1, computed live from the index, ⛔ not stored on a label.

    ⚠️ Standing caveat for whoever claims it: #6021 (domain:services) is vacant, so this priority elevation currently has no reader. It is recorded so it is true when a seat arrives, not because a seat is watching.

    本评论来自分诊座位 Routine，不构成认领。

    Generated by Claude Code

  13. akarma-synetal
    added 3 commits that reference this issue on Aug 17, 2026

    fix(service-datasource): stop serving stored credentials on the datas…

    37b82ed

    fix(metadata-protocol): redact stored credentials on the metadata rea…

    ead96d0

    feat(service-datasource): operator-initiated credential re-homing int…

    3508678
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:servicessecurity

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions