fix(report): 为主编排回注补充 IPC 鉴权 - #779
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f7e7320290
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let response: Response; | ||
| try { | ||
| response = await fetch(`http://127.0.0.1:${daemon.ipcPort}/api/trigger`, { | ||
| response = await fetchDaemonIpc(daemon.ipcPort, '/api/trigger', { |
There was a problem hiding this comment.
On Linux hosts with device credential isolation enabled but the per-bot file sandbox disabled, the credential-only bwrap wrapper deliberately masks .dashboard-secret while leaving the dispatch registry and daemon descriptors readable. This branch is therefore reachable, but fetchDaemonIpc calls loadDaemonIpcSecret() before sending anything and throws, so every registry-backed botmux report still fails instead of reaching the orchestrator. Use a daemon-side relay or a session-scoped capability path rather than requiring the agent process to read the host HMAC secret.
AGENTS.md reference: AGENTS.md:L54-L58
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
已修复。credential-isolated CLI 不再读取 host HMAC：它改为携带当前轮换的 session capability 请求 source daemon 的 /api/report-relay。该 handler 会绑定 live session / turn / dispatch root，从宿主 registry 派生目标身份，并由 daemon 使用 HMAC 转发固定的 untrusted report envelope；调用方提交的 source/target 字段不会被信任。补充的授权与 wiring 回归覆盖了缺失、错误、过期 capability，跨 root/turn、身份夹带、receiver 拒绝和 256 KiB body limit；相关 323/323 测试及 pnpm build 均通过。修复提交：37b64f8a。
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 37b64f8a1f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const originClaim = readManagedOriginCapability( | ||
| resolveDataDir(), | ||
| sid, | ||
| relayDir, | ||
| ); |
There was a problem hiding this comment.
When device credential isolation is enabled but the full file sandbox is disabled, this fallback still cannot authenticate: BOTMUX_SEND_RELAY is unset, while the worker creates neither a Linux relay-outbox capability nor a read-isolation/origin-*.json file for credential-only bwrap, so originClaim is null and /api/report-relay rejects the request with origin_unproven. Fresh evidence after the prior thread is that the new client now reads this capability, but the credential-only worker path was not updated to publish it; therefore the scenario this commit intends to fix still breaks every registry-backed report. Publish a child-readable rotating capability for the credential-only path or provide another session-scoped transport.
AGENTS.md reference: AGENTS.md:L54-L58
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
已补齐 capability 生产端。credential-only worker 现在为每个 session 创建私有轮换目录，bwrap 先用 tmpfs 屏蔽整个 read-isolation 父目录，再只读绑定当前 session 子目录；因此 sibling capability 不可见，同时目录 bind 能观察 atomic rename 后的新 token。worker 在 fresh spawn 与 safe reattach 都会发布当前 session/turn capability，并通过 BOTMUX_ORIGIN_CAPABILITY_DIR 指向该目录；pane marker 升至 v10，使缺少新 mount/env 的旧 pane 强制冷启动。真实 bwrap 验证覆盖了 token v1→v2 轮换可见与 sibling 隐藏，相关 389/389 测试及 pnpm build 通过。修复提交：0f656a86。
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0f656a86ce
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
| if (!willReattachPersistent && credentialOnlyBwrap) { | ||
| let credentialOnlyCapabilityDir: string | undefined; | ||
| if (credentialOnlyBwrap) { |
There was a problem hiding this comment.
On macOS when device credential isolation is active but the full file sandbox is disabled, the credential-only Seatbelt profile masks the host HMAC secret, but this new capability publication is guarded exclusively by credentialOnlyBwrap. The existing macOS capability setup is inside if (sandboxRequested), so this combination has neither the secret nor its own published claim; botmux report consequently submits no originCapability and /api/report-relay rejects every registry-backed report with origin_unproven. Add an equivalent current-session capability transport and carve-out to the credential-only Seatbelt path.
AGENTS.md reference: AGENTS.md:L54-L56
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
已补齐 macOS credential-only Seatbelt。worker 现在对 Seatbelt 与 bwrap 共用同一套 per-session capability 发布与 BOTMUX_ORIGIN_CAPABILITY_DIR 注入；Seatbelt profile 先 deny 整个 read-isolation 父目录，只授予父目录 metadata traversal 和当前 session 子目录 read，并在后序规则继续 deny 父目录 write，因此 sibling capability 不可读、当前轮换文件可读且不可写。pane marker 升至 v11，缺少新 profile/env 的 v10 Seatbelt pane 会冷启动。TDD 用例先复现缺失路径，相关 390/390 测试及 pnpm build 通过。修复提交：88169d58。
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 88169d58f8
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const rawEntry = input.registry[dispatchRoot]; | ||
| const entry = rawEntry && typeof rawEntry === 'object' && !Array.isArray(rawEntry) | ||
| ? rawEntry as Record<string, unknown> | ||
| : undefined; | ||
| const targetLarkAppId = typeof entry?.orchAppId === 'string' ? entry.orchAppId.trim() : ''; | ||
| const targetSessionId = typeof entry?.orchSessionId === 'string' | ||
| ? entry.orchSessionId.trim() | ||
| : ''; |
There was a problem hiding this comment.
When device credential isolation is enabled without the full file sandbox, both credential-only wrappers still permit writes to orchestrate-dispatch.json (bwrap binds / read-write, while the Seatbelt profile only protects credential/profile paths). An isolated CLI can therefore copy any other live orchAppId/orchSessionId tuple from the readable registry into its own capability-bound dispatch-root entry, then call this relay; these lines treat that caller-modified entry as trusted and send an HMAC-authenticated trigger into the victim session. Bind the target to host-owned immutable provenance, authenticate registry entries, or make this registry host-write-only before using it as an authorization source.
AGENTS.md reference: AGENTS.md:L54-L58
Useful? React with 👍 / 👎.
Review: 有 blocking 问题，暂不可合在 head P1｜新 capability 目录穿不过默认 tmux 后端 → Linux 隔离 report 必 403
建议：把该 key 纳入 P1｜目标派生不是真正"服务端可信派生"，registry 可被隔离 CLI 改写（confused deputy）credential-only bwrap 的底座是 授权函数只把 复现：隔离 CLI 合法拥有自己的 root 需要修正"忽略 body 自带 target 即安全"的假设：忽略 body 只挡住了一个入口，真正的 target 来源（registry entry 值）仍可被调用方篡改。 建议：target 绑定必须来自 daemon-owned 的不可变 provenance，或宿主签名的 registry entry，或等价的不可由 CLI 改写的授权状态；仅"忽略 body 自带 target"不够。 P1（可达性）｜隔离分支在 relay 前仍依赖 CLI 本地 registry lookup两条 relay 分支（直连签名 + 隔离 relay）都嵌在同一个
结果：当前 relay 分支实际只在 credential-only bwrap（registry 可见）那一档可达，而那一档正好被上面两个 P1 咬住。注意：把 registry 判定挪到 daemon 侧修可达性时，不会自动修上面的完整性问题——daemon 读的就是同一份 CLI 可写的真实文件。可达性与完整性需要一起解决，否则等于把"够不着"变成"够得着但可被劫持"。 建议：隔离分支应凭显式 root + session capability 更早进入 source-daemon relay，由 daemon 做 registry 判定；同时该 registry 判定所依赖的 entry 必须是 CLI 不可改写的。 P2｜type-ahead 会把合法 live turn 误判为 stale
当用户在子任务执行途中补一条消息，当前 capability 对执行轮仍然合法，但授权要求 建议：thread scope 只需把当前 capability 绑到稳定的 session root；chat scope 应查 exact per-turn 的 两个非阻塞
|
|
已在 blocking 修复：
验证结果：11 个相关测试文件共 255/255 通过； |
合并 origin/master（31a71268）并解决冲突。 为持久后端透传 managed-origin channel；由 daemon 签发并校验 dispatch binding，避免 registry 目标篡改；按 live turn reply target 处理 type-ahead。
70f772c to
4a6ea6c
Compare
2 participants
改动
origin/master（31a71268）并解决全部冲突。botmux report在可读取宿主密钥时继续使用fetchDaemonIpc，为最终/api/trigger请求携带 HMAC 鉴权。BOTMUX_ORIGIN_CHANNEL_ID；worker/daemon 在独立目录内原子轮换当前 session/turn capability。.dashboard-secret，所以 report 仍优先走宿主 HMAC，而不是 capability relay。orchAppId/orchSessionId/title；source daemon 只采用验签后的 binding，因此合法会话篡改 registry 不能把回报劫持到其他会话。--dispatch-root不再依赖 CLI 本地 registry。quoteTargetId误判 stale；chat 回报使用replyTargets[liveTurnId]精确槽位，仅在单槽明确属于同一 live turn 时兼容回退。旧轮 capability 仍会被拒绝。report-session-relay.ts中实际已使用参数的下划线前缀，统一为input / decision / meta。原因
原实现直接向 loopback
/api/trigger发请求，缺少X-Botmux-Cli-*鉴权头，会被 daemon 以401 missing_headers拒绝。仅改用宿主 HMAC 仍覆盖不了屏蔽.dashboard-secret的隔离环境；仅把 lookup 移进 daemon 又会让可写 registry 成为 confused-deputy 的目标来源。当前方案同时解决传输、可达性与完整性：隔离 CLI 只向自己的 source daemon 提交当前轮 capability；dispatch 目标由 daemon 签名并在 relay 时验签；最终跨 daemon 的
/api/trigger仍由宿主使用 HMAC 发出。安全边界
trusted: false，固定 instruction 明确把 report body 当作不可信数据。兼容性与影响面
验证
pnpm build通过：domain audit、TypeScript、runtime build id、dashboard bundle、dist audit 均成功。