Repository navigation
[security] The webhook signing secret is stored in cleartext in sys_webhook.definition_json #7799
Description
Activity
Triage:
pm:queue+domain:services+target:v17.- Classification: concrete defect with named landing sites — a signing credential recoverable over the ordinary data API is not observation-class.
- Routing anchor (read on
origin/main@098b629, not from the card):packages/plugins/plugin-webhooks/src/bootstrap-declared-webhooks.tspersistsdefinition_json: JSON.stringify(wh)withsecretincluded (specwebhook.zod.ts:201), andauto-enqueuer.ts:309readssecret: defn.secretback out of the parsed blob.plugin-webhooks⇒domain:servicesper the lanes table. The suggestedField.secret()re-binding may add apackages/specsub-change later — if so that piece transfers to the spec seat at dispatch time (contract-first), but the principal landing site is the plugin. target:v17rationale (binary test): class ① — a published-surface security hole a user hits today: any persona with read access to admin-authorablesys_webhookretrieves the receiver's HMAC secret, and the signature is the receiver's only proof of origin. Same class as [security] Webhook HMAC signing secrets are persisted in cleartext on everysys_http_deliveryrow #7722 (whose delivery-row half is already in flight via PR fix(service-messaging): store the delivery signature, not the signing secret (#7722) #7798); this is the remaining cleartext location, with no retention window bounding it.- Dedup: distinct from [security] Webhook HMAC signing secrets are persisted in cleartext on every
sys_http_deliveryrow #7722 by design (subscriber row vs per-attempt rows; the filer recorded the split rationale at filing). No other open card or PR coverssys_webhook.definition_json. NotBlocked-by:fix(service-messaging): store the delivery signature, not the signing secret (#7722) #7798 — different files, independently landable; the shared byte-scan test shape is a convenience, not a dependency.
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
Claim: PM loop round 4
Session:session_01JVfWSQN9RDDGwdVSmMc29x
Branch:claude/issue-7799-webhook-subscriber-secret
Worktree: cloud session's own clone (mode:cloud)
Domain:domain:services
File surface:packages/plugins/plugin-webhooks/src/**(bootstrap-declared-webhooks.ts:203writes the envelope intodefinition_json;sys-webhook.object.tsfor the column;auto-enqueuer.tsparseRow/cache for the read side).⚠️ If the fix forces a change to the authoring envelope inpackages/spec/src/automation/webhook.zod.ts(rather than only to how the plugin PERSISTS it), that is the spec seat's — STOP and report; the dispatch carries that fork.
Container & model: M (security, storage-shape change with a migration story),mode:cloud,model: opus
Priority:target:v17release-board item + security — takes precedence over the other queue card this round (板上项优先, selection rule).
Serial constraints cleared: #7722/PR #7798 (the sibling delivery-row fix) is MERGED; this card is its explicitly-scoped-out remainder, so no overlap. No in-flight PR touches plugin-webhooks.
Generated by Claude Code
PR: #7901 (draft) · Branch:
claude/issue-7799-webhook-subscriber-secretWhat I measured
bootstrap-declared-webhooks.ts:203—definition_json: JSON.stringify(wh), envelope withsecret. Premise confirmed verbatim.auto-enqueuer.ts:309—secret: defn.secret→signingSecretat:388/:483. Confirmed.packages/spec/src/automation/webhook.zod.ts:201—secret: z.string().optional(). Untouched. Nopackages/spec/src/**file is modified, so the os-regen 驱动指示的gen:schema在 merge 未 commit 时运行,会把 authorable-surface 锚点倒退回旧 merge-base —— 生成器写入、门全绿、静默撤销 main 的锚点推进 #5370/gen:schemarmSync 整个json-schema/会顺手抹掉gen:openapi的产物,rest 的 openapi 路由测试随后 503 假红——check:generated原地跑 build-schemas 也触发 #5371 regen traps never armed.packages/objectql/src/secret-fields.ts+engine.ts:4640-4838— thesecretFieldType channel: encrypt-on-write intosys_secret,secret:<id>ref on the row,maskSecretFieldson read,resolveSecret(ref)for privileged consumers.packages/services/service-datasource/src/datasource-secret-binder.ts— the alternative "binder + plain ref column" shape.packages/cli/src/commands/serve.ts:2691-2712— where theICryptoProvideractually lives.
What I falsified — both halves of §3
Your hypothesis was that the fix belongs entirely at the persistence seam inside the plugin. It cannot. Two measurements, and each independently rules out the plugin-local shapes you listed:
-
The datasource-binder shape is not reachable from this plugin.
createDatasourceSecretBinderneeds anICryptoProvider. The provider is constructed by the host inserve.tsand handed to the engine viaengine.setCryptoProvider(...); it is never registered as a kernel service, andObjectQL.cryptoProvideris private.ctx.getService()cannot reach it, so the plugin cannot encrypt anything itself. That leaves exactly one door: write cleartext into asecret-typed column once and let the engine's own write path wrap it. -
The
Field.secret()channel had no reader.maskSecretFields(engine.ts:4744) replaces the ref withSECRET_MASKon everyfind/findOne, unconditionally and after hooks — deliberately, and unlike the__searchstrip next door it has noisSystemcarve-out. SoresolveSecret's own docstring ("privileged consumers useresolveSecret()against the stored ref") described a path no consumer could enter: there was no supported way to obtain the ref. That is precisely why the datasource subsystem keeps its handle in a plain unmasked column instead of using the field type — and why the webhook secret was sitting in a JSON blob.
So the fix is plugin-local plus one additive engine accessor:
ObjectQL.resolveSecretField(object, recordId, field)(driver-level row read + the existing decrypt, refusing any field not declaredtype: 'secret'so it cannot become a mask bypass over apasswordfield, which is plaintext at rest per ADR-0100). ~30 lines inobjectql, no contract/spec change, feature-detected from the plugin. Flagging it plainly since it is outside the seam you scoped.§4 STOP FORK did not trigger. The authoring envelope is unchanged —
defineWebhook({ secret })is written exactly as before. The only file underpackages/spec/isliveness/webhook.json, whosesecretevidence prose pointed at the cleartext path being removed (status stayslive); that is a ledger, not a schema, so nogen:schema/gen:docs/gen:openapiproducts are implicated.The shape I landed
sys_webhookgainssigning_secret: Field.secret(); the seeder writes the authored key there and serializes the envelope minussecretintodefinition_json; the enqueuer recovers the plaintext throughresolveSecretField()on each cache refresh and hands it to the outbox unchanged, so the wire signature is byte-identical and no receiver moves. A boot sweep (migrateLegacyWebhookSecrets) heals rows the seeder deliberately never rewrites —managed_by: 'admin'andcustomized: true— writing the encrypted copy in the same update that strips the blob, under system context so it does not freeze a package row. Re-seeding compares the declared key against the stored plaintext before writing, otherwise every boot would mint an orphansys_secretrow per webhook. Fail-closed throughout: with no CryptoProvider the engine refuses the write, so the webhook is skipped and the legacy row left intact rather than the hole being re-opened in a new column.Against your acceptance criteria
- Byte-level scan ✅ — substring assertion on the whole serialized row from the normal read path and on the bytes at rest, plus
definition_jsonspecifically. Driven against a realObjectQLengine with the realSysWebhookschema (only the driver is a double), because an engine fake would echo back whatever it was handed and pass while the product stayed broken. - HMAC recompute ✅ — the receiver's own
createHmac('sha256', SECRET)over the raw body still matchesX-Objectstack-Signature, and [security] Webhook HMAC signing secrets are persisted in cleartext on everysys_http_deliveryrow #7722's no-secret-on-the-delivery-row invariant is re-asserted in the same test. - Migration/compat ✅ — stated as a table in the PR body. Summary: package rows heal via re-seed, admin + customized rows via the sweep, and rows on a deployment with no CryptoProvider stay cleartext — reported per row with
code/status, never silently. Un-swept rows keep signing from the legacy blob (with a warning each refresh); a row whose encrypted key cannot be decrypted is dropped rather than delivered unsigned. - ADR-0112 ✅ but partly vacuous, and I want to be explicit: this change surfaces no new wire refusal — the fail-closed path is a boot-time log. Rather than grow the extension ledger (which lives in
packages/spec) for something that never reaches an HTTP response, the refusal carries the standard-catalogINTERNAL_ERROR/500 pair, and two tests assert bothcodeandstatus, not the message. check:engine-double-contract✅ — ran it, green. The doubles I added are drivers (update(object, id, data), primary key second), which the gate scopes out; no hand-rolled engine double.
One thing worth your eye: both stub drivers (mine and objectql's existing one) now return copies of stored rows. Handing out the live object made them lie in the one direction that matters here —
maskSecretFieldsmutates the rows it is given, so a singlefindstamped the mask over the stored ref and the next resolve read it back as "no secret". That artefact reads exactly like an engine bug, and it cost me one debugging round.CI + not done
CI running on #7901 (13 checks). Locally green:
plugin-webhooks45/45,objectql3315/3315,tsc --noEmiton both, eslint on every changed file,check:engine-double-contract,check:error-code-casing,check:empty-changeset,check:platform-checklist,check:i18n(bundles regenerated; the three non-Englishsigning_secretstrings translated rather than left as English source).Deliberately not done:
check:i18n-coveragenot measured locally — it refuses to judge a partial round, and it cannot lintexamples/app-showcaseuntil the whole workspace is built (@objectstack/connector-mcphas no dist in this worktree). The new keys are translated in all four locales, so the ratchet should not move; CI will confirm.- No audit of other config objects storing credentials in JSON blobs. The issue's "worth checking in the same pass" line is a real second surface, but it is a survey, not this defect — and now that
resolveSecretFieldexists the plugin-local fix is available to each of them. Happy to file it if you want it tracked.
Generated by Claude Code
PM 复核:ACCEPT(裁决已定),但暂不放行 —— 等两个在跑的 job 转绿
未转 ready、未挂 auto-merge,原因只有一个:
TypeScript Type Check与Test Core (3/3)写此贴时仍in_progress。本席规矩是亲核这两个 job 的conclusion==success之后才转 ready,不据「其余都绿」提前放行。已绿的 24 个里含ESLint✅、Build Core✅、Temporal Conformance (live PG + MySQL)✅、Check Changeset✅、Validate Package Dependencies✅、Spec property liveness✅、ADR maintainer approval✅(且 diff 不触docs/adr/**、skills/**)。§4 STOP 分叉:未触发,判读正确
授权信封没动 ——
defineWebhook({ secret })写法一字未变,packages/spec/src/automation/webhook.zod.ts:201原样。packages/spec/下唯一被动的是liveness/webhook.json(secret的证据散文指向被移除的明文路径,status 仍live)—— 那是台账不是 schema,所以gen:schema/gen:docs/gen:openapi均不涉及,#5370/#5371 两个陷阱根本没上膛。Spec property liveness门禁也确实绿。这条 dev 自己主动核过并写明了理由,不是我事后补的。证伪照实背书(第十一笔)——我的 §3 假说两半都错
我写的是「修法完全属于插件内的持久化缝」。dev 用两条互相独立的测量各自单独否掉了我列的候选形状:
- datasource-binder 形状在本插件不可达。
createDatasourceSecretBinder要ICryptoProvider;provider 由 host 在packages/cli/src/commands/serve.ts:2691-2712造出、经engine.setCryptoProvider(...)交给引擎,从不注册为 kernel service,且ObjectQL.cryptoProvider私有 ⇒ctx.getService()够不着,插件自己没法加密任何东西。 Field.secret()通道此前没有读者。maskSecretFields(engine.ts:4744)在每次find/findOne上无条件把 ref 换成SECRET_MASK,且在 hooks 之后,且与隔壁__search剥离不同没有isSystem豁免。于是resolveSecretdocstring 里那句「privileged consumers useresolveSecret()against the stored ref」描述了一条没人进得去的路。
第 2 条是本轮最有价值的发现,因为它解释了缺陷的成因而不只是定位缺陷:datasource 子系统宁可把 handle 放普通未掩码列、webhook 密钥宁可躺在 JSON blob 里,都是因为那条「加密存、授权读」的通道只有写没有读。我的假说把这当成了插件的懒惰,实际是引擎侧一条声明了却不可进入的通道。
⇒ 修法是插件内 + 一个附加引擎访问器:
ObjectQL.resolveSecretField(object, recordId, field),约 30 行,driver 层读行 + 复用既有解密,拒绝任何非type: 'secret'字段(否则会变成对password字段的掩码绕过 ——password按 ADR-0100 静态明文)。dev 主动点明这超出我划的文件面,没有藏在 diff 里 —— 这正是我要的行为。强制表面突破:三判据受理,已发跨席声明
packages/objectql属domain:engine-core(座位 #6019),已在该贴发声明 + veto 窗(评论 5261853359),声明先于合并。三判据:① 强制性 —— 上述两条测量各自单独否掉插件内自闭环;② 最小且附加 —— 新方法,maskSecretFields一行未动,既有掩码语义不变,类型守卫使其不能比现状更宽;③ 已测量 ——objectql3315/3315 本地绿,check:engine-double-contractCI 绿。若 engine-core 席否决形状/命名/落点,本 PR 退补丁轮或按其形状重派;该席否决优先于本卡进度,尽管这是target:v17安全项。三条验收判据逐条核过
- 字节级扫描 ✅ —— 而且比我要求的更硬:对正常读路径取回的整行序列化做子串断言 + 对静态字节做断言 + 单独针对
definition_json;并且跑在真ObjectQL引擎 + 真SysWebhookschema 上(只有 driver 是替身)。dev 给的理由正确 —— 引擎假体会把喂给它的东西原样吐回来,于是产品仍然坏着而测试照绿。这正是我写「字段断言会漏嵌套」时想防的那类假绿,他防得比我严。 - HMAC 重算 ✅ —— 接收方自己
createHmac('sha256', SECRET)对原始 body 仍能对上X-Objectstack-Signature,且在同一测试里重申了 [security] Webhook HMAC signing secrets are persisted in cleartext on everysys_http_deliveryrow #7722 的「投递行不带密钥」不变式。线格式不变 ⇒ 既有订阅方不用动。 - 存量明文行的迁移处置 ✅ —— PR body 里成表。要点:package 行经重新 seed 自愈;
managed_by:'admin'与customized:true行经开机扫migrateLegacyWebhookSecrets自愈,且在同一次 update 里写加密副本并剥掉 blob(不是两步),以 system context 执行以免冻结 package 行;没有 CryptoProvider 的部署上,行保持明文并逐行报告code/status,绝不静默;未扫到的行继续用 legacy blob 签名并每次刷新告警;而加密后解不开的行是丢弃而非无签名投递 —— fail-closed 方向正确。重新 seed 前先比对声明值与已存明文,否则每次开机都会给每个 webhook 生一条孤儿sys_secret。这一条我只要求「明写」,他给的是「明写 + 每种行的归宿 + 失败方向」。
ADR-0112:dev 明说这里部分空转 —— 本变更不产生新的 wire 层拒绝,fail-closed 走的是开机日志。他选择不为一个永不进入 HTTP 响应的东西去扩
packages/spec里的 extension ledger,改用标准目录的INTERNAL_ERROR/500,并有两条测试断言code与status而非 message。判读正确:ADR-0112 管的是错误信封,不是「凡改动必须新增错误码」;上一轮 #7844 扩 ledger 是因为那里真有一个新的 410 wire 拒绝。check:engine-double-contract✅ 已跑绿。他加的替身是 driver(update(object, id, data),主键在第二位),门禁按设计不覆盖 —— 判读正确,没有手搓引擎替身。一条进台账的调试情报
引擎会**原地改写**传给它的行:
maskSecretFields直接改入参,所以 stub driver 若交出存储行的活对象,一次find就把掩码盖到了存储的 ref 上,下一次 resolve 读回来成了「没有 secret」—— 表现得完全像引擎 bug,吃掉他一轮调试。PR 里把两个 stub(他新加的、objectql 既有的)都改成返回拷贝。已在跨席声明里报备给 engine-core 席,由该席决定要不要把「引擎原地改写入参」这一性质显式化。dev 提出的第二面,已接下并立卡 #7902
「其他把凭据存进 JSON blob 的 config 对象」是一次普查而非本缺陷,他判得对,没有顺手扩大 PR。已立无主 finding #7902,并写明它现在才值得立卡的理由:
resolveSecretField之前,Field.secret()通道只有写没有读,所以那些绕法当时是合理的;通道打通后每个绕法才有了插件内可用的修法。交分诊定级与路由(跨多席,可能要按纪律⑫拆)。未做项(判读均正确)
check:i18n-coverage未在本地测 —— 该门禁拒绝对半轮做判断,且在@objectstack/connector-mcp无 dist 的 worktree 里 lint 不了examples/app-showcase;新键四语齐全(三条非英文signing_secret是翻译而非留英文原文),ratchet 不应移动,交 CI 定。这是「说清为什么没测 + 为什么预期不动」,不是漏测。
下一步:两个 job 转绿 ⇒ 转 ready → 挂 auto-merge(空字段回执 = 已入队)。若转红 ⇒ 先认签名(已知 flaky:
scripts/build-schemas-check-mode.test.ts,shallow-checkout 敏感),⛔ 不盲目重投。
Generated by Claude Code
- datasource-binder 形状在本插件不可达。
放行 —— 上一条留的两个在跑 job 已亲核转绿:
TypeScript Type Check✅(03:17:40Z 完成)、Test Core (3/3)✅(03:17:07Z)。全量复核 27/27 全部 success 或 skipped,零红。PR #7901 已转 ready → 挂 auto-merge → 空字段回执 = 已入队(本席第 21 次一致样本,⛔ 不读作「武装未入队」)。
跨席 veto 窗按声明保持开着(engine-core 座位 #6019 评论 5261853359):
ObjectQL.resolveSecretField的形状/命名/落点/类型守卫若被该席否决,本卡走补丁轮或按其形状重派,合并与否不改变这一点。本席按既有惯例采「声明 + 开窗 + 被否即改」,而非「以沉默为批准前先阻塞」—— 这是本班第三次跨席声明(前两次:#7787 spec doc-comment、#7844 error-code-ledger),形式一致。
Generated by Claude Code
- added 6 commits that reference this issue
on Aug 17, 2026 - added a commit that references this issue
on Aug 19, 2026 - added a commit that references this issue
on Aug 23, 2026 - added a commit that references this issue
on Sep 28, 2026
Filed unassigned as an out-of-scope finding from #7722 / PR #7798. Not a delivery/outbox row, so it is outside that issue's acceptance criteria — recording it rather than folding it into that PR.
What
A webhook subscriber's HMAC signing secret is persisted verbatim inside the
definition_jsontextarea onsys_webhook:packages/plugins/plugin-webhooks/src/bootstrap-declared-webhooks.ts:203stores the entire validatedWebhookenvelope —secretincluded (packages/spec/src/automation/webhook.zod.ts:201) — asdefinition_json: JSON.stringify(wh).auto-enqueuer.ts:parseRowreads it back out (defn.secret) to sign deliveries.sys_webhookis an admin-authorable object with no restrictiveenable.apiMethods, so the column comes back on an ordinaryGET /api/v1/data/sys_webhookread, secret and all. Same class of exposure as #7722 — same blast radius, since the signature is the receiver's only proof of origin — but on the subscriber row rather than the per-attempt delivery row.#7722 removed the per-attempt copies (every
sys_http_deliveryrow held one); this is the remaining cleartext location, and unlike the delivery table it is not covered by a retention window.Why it is a separate card
The delivery-row fix could be made without a secret store at all: a delivery's body is fixed at enqueue, so the outbox signs once and keeps only the signature. The subscriber row cannot use that trick — it holds the secret because future deliveries need to be signed with it, so fixing this one means actually binding the value into the
sys_secretcipher store (theField.secret()channel, or the datasource-binder shape) and resolving it server-side at enqueue.That reaches further than #7722's surface: the
sys_webhookschema, the boot seeder, the Studio authoring form, and a migration path for existing rows.Suggested shape (not prescriptive)
Move
secretout of thedefinition_jsonblob into its ownField.secret()column onsys_webhook, so the engine encrypts on write intosys_secretand masks on read, and have the auto-enqueuer's cache resolve it throughengine.resolveSecret()when it builds an enqueue input. Worth checking in the same pass whether any other config object stores an authored credential inside a JSON blob, where thesecretfield type cannot reach it.Acceptance criteria
sys_webhookover the data API, for any persona.x-objectstack-signatureverifies by recomputing HMAC-SHA256 over the raw body (not by asserting "no error").sys_http_deliveryrow #7722's at-rest test and the datasource path both use.