[wip ai slop] Add trusted Phase 1 receipt controls / 新增阶段 1 可信回执控制 - #3298
functionstackx wants to merge 2 commits into
Conversation
…ation Land hosted source/publication issuance, exact immutable artifact transport, and independently tested Python client foundations without changing native pilot selection, matrix routing, or allocation. Document reader-first deployment and reviewed issuer/reader pins before a producer qualification change. 中文：在 native 验收前加入受信测量回执控制。提供托管源回执与发布记录 签发、准确的不可变产物传输，以及经过独立测试的 Python 客户端基础； 不改变 native pilot 选择、矩阵路由或资源分配。文档明确先部署读取端， 再部署已审查签发版本，最后通过独立变更开展产出端验收。 Validation: all 41 tests in the five requested suites pass, including installed wheel resources; Ruff checks and formatting pass for all 109 infx files. The four changed workflows pass the strict auditor-mode zizmor check locally (offline action-reference checks); no Slurm or production database execution. 验证：指定五组测试共 41 项全部通过，其中包含安装后的 wheel 资源验证； 全部 109 个 infx 文件通过 Ruff 检查和格式检查。四个变更工作流通过本地 严格 auditor 模式的 zizmor 检查（未进行在线 action 引用验证）；未执行 Slurm 任务，也未写入生产数据库。
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.
This automated review ran and confirmed the inline timeout finding. Beyond that, I independently checked two other flagged candidates and ruled them out: in receipt_transport.py, an unconfigured INFX_RECEIPT_ISSUER_SHAS allowlist raises a plain ValueError rather than PendingReceiptError, so --defer-unsealed intentionally hard-fails on missing issuer configuration instead of silently deferring forever; and in cache.py, retained quarantined snapshots are documented in-code as intentional diagnostic evidence for operators, not an unacknowledged leak. Given the size and security sensitivity of this change (subprocess/gh api usage, secret-name denylisting, archive extraction, receipt signing), a human review remains warranted.
Extended reasoning...
This is the narrow findings-present exception: a CONFIRMED inline finding already exists (missing subprocess timeout on the new gh api wrapper in phase1_publication.py, used across the receipt/publication pipeline and reused by phase1_record.py), which I verified directly by reading the file — line 76 calls subprocess.run(argv, capture_output=True, text=True, check=True) with no timeout kwarg, unlike the sibling infx.github.api() convention. Since inline findings already signal that human review is needed, I did not restate them. I additionally spent time verifying two of the five previously-ruled-out candidates myself rather than taking the ruled-out list at face value: (1) receipt_transport.py resolve_transport raises a bare ValueError (not PendingReceiptError) when the issuer SHA allowlist is empty/unset (lines 104-105), so it is not caught by the except PendingReceiptError in main() and the --defer-unsealed flag does not swallow it — reading the surrounding logic, this looks like intended behavior (an unconfigured allowlist is a deployment misconfiguration that should fail loudly rather than be treated as an indefinitely "pending" state), so I agree it's not a bug; (2) cache.py's _quarantine() renames corrupted cache snapshots aside and a code comment documents this as intentional retention for diagnosis by operators of persistent self-hosted runners, which is a reasonable operational tradeoff rather than a defect. Given the PR's scope (new trusted receipt/publication pipeline touching subprocess calls to GitHub's API, secret-name filtering for benchmark client environments, and archive extraction) and the presence of a confirmed reliability finding, this does not meet the bar for approval; a brief defer note adding the above verification is appropriate rather than staying fully silent, since it records genuinely new verification work beyond the existing findings list.
| argv = ["gh", "api", path] | ||
| if paginate: | ||
| argv.extend(("--paginate", "--slurp")) | ||
| return decode_json(subprocess.run(argv, capture_output=True, text=True, check=True).stdout) |
There was a problem hiding this comment.
🟡 (optional) Every new gh api call in the receipt/publication pipeline omits a timeout, unlike the sibling infx.github.api() convention (timeout=60) elsewhere in this diff. A stalled gh api process hangs the trusted phase1-receipt, recover-reused-ingest, run-sweep and stage-results jobs for GitHub Actions' 360-minute default, since none of these workflows set timeout-minutes. Fix: add a bounded timeout to every subprocess.run/check_output gh api call here. Sites: infx/workflows/phase1_publication.py:76,119; infx/workflows/phase1_record.py:35; infx/workflows/receipt_transport.py:57; infx/results/publication_receipt.py:447,450.
Extended reasoning...
phase1_publication.py:76 defines api() calling subprocess.run(argv, capture_output=True, text=True, check=True) with no timeout kwarg. phase1_record.py imports this same api() (line 18) and calls it 4 times in validate_record for metadata/issuer/source/merge lookups (lines 25,62,90,102). None of these, nor the raw zip-download subprocess.run calls at phase1_publication.py:119-127, phase1_record.py:35-37, receipt_transport.py:57-61, or publication_receipt.py:447,450, pass timeout=. Contrast infx/github.py:50-58, used by resolve_transport in the same diff, which sets timeout=60. If the gh CLI or GitHub API stalls (rate limit backoff, TLS hang, DNS issue), the subprocess.run call blocks forever; the job then runs until GitHub Actions' default 360-minute job timeout since phase1-receipt.yml, recover-reused-ingest.yml, run-sweep.yml and stage-results.yml set no timeout-minutes. That blocks receipt sealing, publication recording, ingest recovery, and staging for up to 6 hours per stuck run, consuming a runner and delaying every phase-1 measurement release that depends on this pipeline.
Verification: nit. The missing-timeout claim is factually accurate across every cited site. phase1_publication.py:76 — return decode_json(subprocess.run(argv, capture_output=True, text=True, check=True).stdout) has no timeout=; this api() is imported by phase1_record.py:18 and called at lines 25, 62, 90, 102. The raw gh api ... /zip downloads at phase1_publication.py:119-127, phase1_record.py:35-37,…
Hash ZIP members in bounded chunks, retain CRC and measured-size validation, and parse evaluation samples one line at a time. Cover real large archives, bounded memory, corrupted CRCs, and false member sizes. 分块计算回执 ZIP 成员哈希，保留 CRC 与实际大小校验，并逐行解析评估样本。新增真实大归档、内存上限、CRC 损坏及成员大小不符的行为测试，并同步中英文文档。
This branch has not been deployed
1 participant
Add the trusted control prerequisite for Phase 1: immutable measurement receipts, independently reviewed nine-point expectations, exact artifact-ID/digest transport, and later publication records. Staging and recovery validate accepted records; automatic production dispatch defers while native sealing is pending. Python client/validation foundations are included, but this branch does not select or allocate the H100 pilot.
Land this prerequisite only after deploying the app reader in SemiAnalysisAI/InferenceX-app#1179. Configure the deployed reader and issuer SHA/workflow allowlists before producer qualification. The native runtime prerequisite is SemiAnalysisAI/srt-slurm#21. The H100 producer is a separate child commit/PR. No hardware qualification or production deployment is claimed.
Large ZIP members are hashed in bounded chunks and eval samples are parsed line by line, retaining CRC, size, identity and score checks. Real 64 MiB ZIP and 32 MiB sample regressions stay below 8 MiB of peak Python allocations.
Validation: GitHub CI 35476964027 passed on
c4af40de63cb5352e1bf1a725e7d8f07752c3441: 1,836 tests passed, one skipped; MCP compatibility, Ruff and formatting passed. All 44 focused client/preparation/receipt/transport tests passed locally. Workflow security and the strict Zizmor auditor passed. Seedocs/measurement-receipts.mdand its Chinese counterpart for operator contracts.AI model disclosure
Codex is described by this runtime as based on GPT-6; the exact model/version identifier was not exposed and could not be verified. The primary agent integrated the change; delegated agents using the inherited runtime implemented and reviewed native execution, Python clients, receipts and app readers.
中文
新增阶段 1 的可信控制前置能力：不可变测量回执、独立审阅的九点预期、按精确 artifact ID/digest 传输，以及后续发布记录。Staging 和恢复验证已接受记录；原生测量尚未签发时，自动生产 dispatch 暂缓。本分支包含 Python 客户端与验证基础，但不选择或申请 H100 试点资源。
应先部署 SemiAnalysisAI/InferenceX-app#1179 中的 app reader，再合入本前置能力；producer 验收前配置已部署 reader 和 issuer SHA/workflow allowlist。原生运行时前置能力见 https://github.com/SemiAnalysisAI/srt-slurm/pull/21。H100 producer 使用独立子提交/PR。本次不声称已完成硬件验收或生产部署。
大型 ZIP 成员按块计算哈希，eval 样本逐行解析，保留 CRC、大小、身份与分数校验。真实 64 MiB ZIP 与 32 MiB 样本回归的 Python 峰值分配均低于 8 MiB。
验证：GitHub CI 35476964027 在
c4af40de63cb5352e1bf1a725e7d8f07752c3441上通过：1,836 项测试通过、1 项跳过，MCP 兼容性、Ruff 和格式检查通过。本地 44 项客户端、准备、回执、传输定向测试全部通过；workflow 安全及严格 Zizmor auditor 检查通过。操作契约见docs/measurement-receipts.md及中文对应页。AI 模型披露：运行时将 Codex 描述为基于 GPT-6，但未暴露可核实的精确模型/版本。主代理负责集成，继承相同运行时的子代理负责原生执行、Python 客户端、回执与 app reader 的实现和审阅。