Self-managed bundle rejects a consumer's wrapper Pi launcher before spawn

[frankekn]

Summary

The operator-managed self-managed bundle refuses to start when a consumer sets PI_BIN to its own wrapper script, failing before Pi is spawned with a 54-byte stderr:

Managed Needlefish rejected an unapproved Pi launcher

This blocks the pi runner lane for SaiensCreditSystemRails and currently has no in-consumer workaround.

Where the check lives

The rejection string is not in this repository at any ref, and not in the consumer repository:

• git grep unapproved over all local/remote refs of this repo: no match.
• Same search over frankekn/SaiensCreditSystemRails at origin/main: no match.
• Upstream launcher resolution is src/shared/codex.ts:1198 -> command: process.env.PI_BIN ?? "pi", with no launcher-identity or allowlist check. RUNNER_ENV_ALLOWLIST.pi (src/shared/codex.ts:83-100) already passes PI_BIN through.

So the check is introduced by the operator-provided self-managed.patch that ships inside the installed release, which is provisioned by hand per README ("Provision the tested self-managed bundle as the runner service account under ~/.local/share/needlefish-self/releases/<self_version>"). Because installation is managed outside CI, the authoritative bytes exist only on the runner and are not under version control.

Reproduction

Consumer: frankekn/SaiensCreditSystemRails, runner label saiens-needlefish-local-proxy (ubuntu-saiens-deploy-x64-1).

Failing gate: the review job step Verify read-only repository evidence contract, which runs node --test policy/.github/scripts/needlefish-repo-integration.test.mjs. That test spawns the installed reviewer binary with PI_BIN pointing at the consumer's wrapper.

Exact runs:

Run	Head	Result
34806706871	ad9f736a90e19a54356e2c819befa2f8fcae83d2 (PR #1188)	Reviewer failed; stderr bytes 54
34810534625	6eea75ed9cfd1c05fa73724e15612c5716d9a2b9 (PR #1210)	Reviewer failed; stderr bytes 54; stderr="Managed Needlefish rejected an unapproved Pi launcher\n"

Why the consumer wraps the launcher

The consumer's .github/scripts/needlefish-pi wrapper exists to pin the review policy: it rejects unexpected argv, requires its own runner session before credentials are reachable, caps temp file size, and strips NODE_OPTIONS/NODE_PATH. Pointing PI_BIN at the raw pi CLI would drop those guarantees.

Attempted in-consumer fixes (all insufficient)

PR #1210 tried adding PI_BIN to NEEDLEFISH_RUNNER_ENV_PASSTHROUGH, a setsid --wait session preflight, and wrapping the reviewer in setsid --wait. The rejection is unchanged, because it happens inside the bundle before spawn.

Ask

Define and document the approved-launcher contract for the self-managed tier:

1. State what makes a launcher approved (path, digest, ownership, or an explicit opt-in env/flag).
2. Let a consumer supply a wrapper that satisfies it, without weakening approved-launcher bytes, session ownership, credential boundaries, or fail-closed evidence.
3. Ship a regression that covers a wrapper PI_BIN, and publish a verifiable release/base SHA plus the matching release.json digests so operators can roll it out.

Please keep the failure fail-closed; the current behaviour is correct in spirit, it just has no approved path for a consumer wrapper.

[frankekn]

更正：根因是過期的 digest pin，不是缺少 approved 路徑

我在原始描述裡把這件事診斷成「self-managed 層沒有給 consumer wrapper 一條 approved 路徑」。取得 runner 存取後看到實際 bytes，那個結論不正確，在此更正。

實際機制

拒絕邏輯在 operator 維護的 lane 檔案 bin/needlefish（不在上游 src，也不在 self-managed.patch — 該 patch 是 0 bytes，patch_sha256 為空字串的 e3b0c442...b855）：

# Only the reviewed Saiens 1188 launcher may keep its private Pi runtime.
...
process.exit(digest === "59ef974ce8440ffb3bc65ce3b716116981a36b734ae793942c88195881db607e" ? 0 : 1);

它把 $PI_BIN 的 SHA256 硬釘在單一值上。所以設計上本來就有 approved wrapper 路徑，只是那顆 pin 指向的是一個已經不存在的版本。

過期經過

對象	.github/scripts/needlefish-pi 的 SHA256
pin 值	59ef974c…
Saiens dc63dfa60（2026-09-10）	59ef974c… 相符
Saiens 現行 main / 全部 7 個 open PR head	02be47c2623e13dbe3c40384e2099771c9555865f4e4d02428477d0ecc09d8fd

pin 對應的是 dc63dfa60 當時的 launcher。之後該腳本在 main 上又被改過多次（f0c2634b1、a0bff1219、f871cad5a、7109271fd、3b0848dbf，其中包含把 ulimit -f 修回 65536），digest 隨之改變，於是 fail closed 生效。這是 pin 正常運作的結果，不是 bundle 缺陷。

0.4.5 與 0.4.6 兩個 release 的 loader 位元完全相同（5c51698e…），所以把 current 切到 0.4.6 不會解除；兩份都帶同一顆過期 pin。

對本 issue 的影響

前述「請定義 approved-launcher 契約」的請求可以降級。真正值得考慮的是這顆 pin 的維運脆弱性：consumer 每次修改自己的 launcher 腳本，都會讓 runner 上的 pin 失效，而且失敗訊息（54 bytes、無 digest 資訊）無法指出是 pin 過期還是真的有人替換了 launcher。可考慮的改善方向：

1. 失敗訊息同時輸出 expected 與 actual digest，讓 operator 一眼看出是過期還是攻擊。
2. 允許 pin 一組 digest，或從 trusted policy checkout 動態推導 expected digest（policy 已由 github.workflow_sha 釘死在 immutable SHA，可作為信任來源）。

短期修復由 operator 在 runner 上把 pin 更新為 02be47c2… 即可，不需要改上游。

[frankekn]

修復已確認

operator 端已把兩個 release（0.4.5、0.4.6）loader 的 pin 更新為 02be47c2…（Saiens 現行 .github/scripts/needlefish-pi 的 SHA256），並同步 managed-lane.json 與 release.json 的 digest。

驗證：Saiens run 34817492457（PR #1188, head ad9f736a）

• Select self-managed Needlefish：success
• Verify read-only repository evidence contract：success（先前在此步驟以 54-byte stderr 失敗）
• Needlefish review：進入實際 review

本 issue 剩下的價值是前面提到的維運改善（失敗訊息輸出 expected／actual digest，或從 trusted policy checkout 推導 expected digest）。短期 blocker 已解除。

[frankekn]

2026-09-16 review 補充：依更正後根因，只追蹤 pin 診斷與安全更新

已讀取 根因更正 與 修復確認。原始短期 blocker 已解除；不是 upstream 不支援 wrapper，也不是 self-managed.patch 缺少核准路徑。 實際是 operator loader 中的 digest pin 過期。前次 review 僅根據 issue 本文提及 private patch 的推論應以上述實際 bytes 的更正為準。

本次不另開「允許任意 launcher」的功能 issue，不要求繞過安全檢查。剩餘改善可限縮為：

最小做法

1. 拒絕時輸出穩定 error code、expected digest、actual digest、loader／bundle version，以及「請管理員核對已核准版本」的下一步。digest 不含秘密；檔案路徑對一般使用者遮蔽，敏感憑證不可輸出。
2. 一般使用者畫面顯示「已安裝工具與管理員核准版本不一致，尚未開始審查」，技術資訊展開或加入使用者確認匯出的診斷包；不需要用戶自己算 SHA256。
3. operator 更新流程先核對／review 新 launcher bytes，再以原有 release metadata 原子更新 pin／manifest／current release，保留可回復版本。不能因 mismatch 自動接受 actual digest，否則 pin 失去用途。
4. 最簡先維持一個已核准 digest。只有 rollout 確實同時存在兩版本才使用小型、版本化 allowlist；不為此建立通用 launcher registry 或動態信任服務。
5. 若改用 policy checkout 推導 expected digest，必須證明該 policy SHA 是獨立可信／已核准來源，不能直接信任待審 PR 自己可修改的 launcher、policy 或 workflow。沒有這項證據就保留 operator 核准 pin。
6. 與 [P2] 記錄實際執行的 review lane，補齊 ACP 身分與 benchmark／安裝版本對應 #149 的 runtime manifest 對齊，記錄 loader/launcher 身分；不要只驗證空 patch/lockfile digest 就聲稱已識別實際 loader。

驗收

• 核准 launcher、合法升級尚未同步 pin、任意替換 bytes 三種情境有可操作診斷；後兩者仍 fail closed。
• 更新後能確認 expected=actual 與新 runtime identity；回滾可恢復已知版本。
• 確認 scope 僅為 operator 維運改善，不把此 issue 當成 [P1/Usability] 非技術使用者的本機開箱即用：安裝包、首次引導、診斷與看得懂的結果 #150/[P1/Usability] GitHub 一次引導啟用：不用手寫 YAML、不需要 self-hosted runner #151 一般 hosted/本機安裝的必要前置。
• 除非有新的受控主機證據，不再把舊 blocker 說成尚未修復。

這則補充未操作任何 runner、沒有更改 pin、認證或部署，只記錄實作與測試建議。