上游同步候选无法使用仓库推送凭据

[jinjunnn]

简明目的

先在“没有写权限”的环境里拉取并检查上游代码，审核通过后才由另一个短时授权步骤推送，避免恶意上游代码偷走仓库权限。

验收改写(owner 2026-09-17 裁决)

• 保留:上游代码只在没有推送权限的候选工作流里跑;推送由另一个工作流在候选全部检查通过后、按候选清单哈希完成(已由 alpha-code#899 / PR [#899][SEC] Split sync-upstream: read-only candidate vs privileged push #1060 交付)。
• 删去:GitHub App 短时令牌与人工审批(AC3 改写)、守卫覆盖新增文件(AC5 改写,与 ADR-035/038 相反)、恶意样本演练(AC6 删除)。下文 Outcome / Scope / Delivery plan 中对应内容不再追。

Outcome（专业定义）

upstream sync 被拆为两个信任域：只读 candidate workflow 检出/恢复/构建/检查并产出不可变 diff evidence；独立 privileged push workflow 只消费已批准 candidate digest，使用短生命周期 GitHub App token，在所有 guard/smoke 通过后推送。Alpha-owned path guard 覆盖 added/modified/deleted/renamed 全部变化并对恶意 fixture fail closed。

Complexity

L — CI 供应链、仓库写权限和不可信代码执行属于高风险安全面。

Context

当前 workflow 可能在持久 push credential 存在时执行未审查上游代码，并在 smoke 前推送；guard 还可能漏掉 added files。仅设置 persist-credentials: false 不足以隔离 job-level secret/permissions。

Scope

• 只读 candidate job 使用最小 contents: read，无 push secret、无持久凭据。
• 禁止/约束 install hooks 与不可信构建副作用，产出可审核 diff/metadata/digest。
• 人工/策略批准后由独立 workflow 获取短时 GitHub App token。
• push 前重新验证 candidate digest、ownership guard、恢复结果和 required smoke。
• guard 覆盖 Alpha-owned/upstream-owned paths 的 A/M/D/R 与文件类型边界。
• 用恶意 upstream fixture 证明 secret、workflow 与 guard 隔离。

Non-goals

• 不自动批准或自动 push 任意 upstream candidate。
• 不在 candidate job 暴露 PAT、长期 App key、environment secret 或 write permission。
• 不保留旧单 job push-before-smoke 流程作为兼容路径。
• 不以文本 diff 人工目测替代机器 guard/digest identity。

Acceptance criteria

AC1. 未审查上游代码只在无仓库写 secret/permission 且 checkout 不持久凭据的 candidate job 中执行。
AC2. candidate 输出包含 base/head、完整 diff、文件状态、检查结果与不可变 digest，可供独立审核。
AC3. 推送是独立工作流,只在候选工作流成功后运行,不执行上游代码;推送凭据只在推送步骤配置,推送的提交哈希必须等于候选产物清单。 (2026-09-17 按 owner 裁决改写,原文见编辑历史)
AC4. ownership guard、restore、生成检查与 required smoke 全部在 push 前通过；失败不会更新目标 branch。
AC5. 上游路径下的修改、删除、改名由 north-star 守卫拦截;新增文件按 ADR-035/038 放行。 (2026-09-17 按 owner 裁决改写,原文见编辑历史)
AC6. 恶意 workflow/package/install fixture 不能读取 push credential、修改批准 artifact 或绕过 guard。 —— 2026-09-17 删除(owner 裁决):演练要先造演练装置,而「上游代码偷推送权限」已由两段工作流结构性隔离。
AC7. 审批、candidate digest、token subject、检查与 push 结果可审计，但日志不含 token/secret。

Evidence map

AC	Evidence surface
AC1	candidate workflow permission/credential audit
AC2	immutable candidate artifact/digest tests
AC3	.github/workflows/sync-upstream-push.yml(workflow_run + conclusion == 'success'、解包哈希核对清单、推送凭据只在推送步骤配置)(2026-09-17 同步)
AC4	push-order workflow test + required-smoke negative fixture
AC5	scripts/north-star-guard.sh(--no-renames --diff-filter=DMR)+ packages/ui-mac/src/main/north-star-guard.test.ts(新增文件不点名)(2026-09-17 同步)
AC6	建议 VERIFY：malicious upstream workflow/install-hook matrix —— 2026-09-17 删除
AC7	redacted supply-chain audit record

Acceptance owner

@jinjunnn(owner 2026-09-17 裁决按证据验收)(2026-09-17 订正,原为「待指定」)

设计要点

• 两阶段必须是独立 job/workflow 信任域，不只是同一 shell script 的两个步骤。
• privileged workflow 不重新执行 candidate 中的不可信 install/build 脚本。
• approval 绑定 exact digest/commit；重新生成候选会使旧批准失效。
• checkout、artifact download 与 push 都做 provenance 校验。

潜在问题与风险

• job-level write permission 即使 checkout 不持久凭据仍可能被不可信代码滥用。
• push-before-smoke 会把失败候选写入目标 branch。
• 只检查 modified/deleted 会允许新增文件覆盖 Alpha-owned 行为。
• privileged 阶段重新构建会引入 TOCTOU，推送的内容可能不是审核对象。

过时性与兼容性结论

需求有效且未完成。旧单 workflow、长期 credential、push-before-smoke 与不完整 guard 不做兼容，直接替换。保留批准/digest 绑定、失败重试、最小权限与审计正确性。

关联与职责边界

• [REQ-084] Alpha 页面通过窄 typed surface 接入路由 #199/[REQ-084][CODE] Run seam tests during frozen-frontend restore and align base-3 authority docs #258 依赖同步后 frozen seam 仍可验证。
• [REQ-089] Alpha route manifest 成为唯一的路由组合真相 #204 依赖同步不能静默恢复旧 route truth。
• 本票拥有 workflow 权限与 guard，不拥有各产品 surface 行为。

Delivery plan / 建议子票

• 建议 CODE：无 secret 的只读 candidate workflow 与不可变 diff artifact。
• 建议 CODE：批准后短时 token 的 privileged push workflow，push 前 smoke。
• 建议 CODE：覆盖 A/M/D/R/added-files 的完整 ownership guard。
• 建议 VERIFY：恶意 workflow、install hook、artifact 替换与 token exfiltration 矩阵。

Dependencies

• 需要可用的 GitHub App 最小权限配置与审核人/策略 owner。
• 未指定 acceptance owner 前不得进入 Ready。

[jinjunnn]

W0 存量普查复核:STILL_REAL(保持 OPEN,置信度 high)

票面要的用户可观察效果
上游 sync 拆成两个信任域——只读、无推送凭据的 candidate 阶段跑不可信上游代码并产出可审计的不可变 diff/digest,批准后才由独立特权 workflow 用短时 token 在全部 guard 与 smoke 通过之后推送;ownership guard 覆盖 A/M/D/R 全部变化。

这件事今天由谁负责
.github/workflows/sync-upstream.yml 里唯一的 sync job(cron 每天 06:00 UTC 仍在跑,line 14-16)承担全部同步职责;alpha-owned 路径守卫由 .github/workflows/alpha-ci.yml 的 upstream-guard job(line 104-210)负责。两者今天都没有实现票面要的分权与 A 覆盖。

实读证据

• .github/workflows/sync-upstream.yml:18-19 — workflow 顶层 permissions: contents: write,且全文只有一个 job(sync,line 26)。不存在只读 candidate 信任域,AC1 的前半句结构上不成立。
• .github/workflows/sync-upstream.yml:44 — token: ${{ secrets.SYNC_TOKEN || github.token }},且没有 persist-credentials: false(全仓只有 docs-locale-sync.yml:21 与 nix-hashes.yml:100 写了这一行)。推送凭据被写进 .git/config 并在同一 job 中长期存在。
• .github/workflows/sync-upstream.yml:159 与 :204 — bun install 在带推送凭据的同一 job 内执行刚合并进来的上游代码(install hook / 依赖脚本),正是 AC1 要禁止的形态。
• .github/workflows/sync-upstream.yml:138 与 :163 — git push --no-verify origin alpha;而 Engine runtime smoke 步骤在 :201-204,排在 push 之后。这就是票面点名的 push-before-smoke,AC4 未达成。
• .github/workflows/alpha-ci.yml:203 — git diff --diff-filter=DMR --name-only origin/dev...HEAD,过滤器只含 Deleted/Modified/Renamed,没有 A。AC5「added files 不再漏检」直接未达成。
• .github/workflows/alpha-ci.yml:160-161 — 注释原文「新增文件对 --diff-filter=DMR 天然不触发,无需 exclude」。这不是疏忽而是当前设计刻意依赖的性质,说明 AC5 不会被别处补上。
• 全仓不存在 candidate artifact / digest / 批准绑定 / GitHub App 短时 token 的任何实现(见 crossCheckAxes 两条零命中),AC2/AC3/AC6/AC7 无施力点。

什么会推翻本结论
如果存在一个我没找到的第二 workflow / composite action / 外部 repo 的 reusable workflow 承担 candidate 阶段(例如 uses: jinjunnn/xxx/.github/workflows/...@ref),或者 sync job 实际被 branch protection 之外的某个 environment 强制人工批准并降权;又或者 alpha-ci 之外另有一道对 Added 文件生效的 alpha-owned 守卫(例如 pre-push 钩子或 scripts/alpha-check.sh 内的一步)。任一成立都会推翻本条。

交叉验证用的两条独立检索轴

• 符号轴:rg -a -l -i "candidate|digest|privileged|app-token|create-github-app-token" .github/ → 只命中 .github/actions/setup-git-committer/action.yml(与两阶段同步无关)。同一条命令对 rg -a -c "sync-upstream" .github/workflows/sync-upstream.yml 返回 2,证明检索手段有效。
• 文件名轴:find . -type f \( -name "*sync*" -o -name "*upstream*" \) | grep -v node_modules → 主 checkout 内只有 .github/workflows/sync-upstream.yml 一个同步 workflow(其余命中是 .worktrees 副本与 docs);ls scripts/ 也没有任何两阶段同步脚本。另跑 gh api repos/jinjunnn/alpha-code/issues/227/timeline 与 gh issue list --search '"#227" in:body',无任何子票或交付 PR。

---

出处:2026-08-10 W0 存量普查第二轮。方法 = 12 个子系统批各自实读代码给出裁决,再对每一条会导致关票的裁决单独派对抗方证伪。本批 6 条关票候选全部被推翻(5 条从 DONE/SUPERSEDED 降为 PARTIAL,1 条方向相反),所以本票保持 OPEN。

[jinjunnn]

owner 2026-09-17 裁决:按证据验收,关闭。

这个需求要防的是「上游代码在同步时偷走仓库推送权限」。alpha-code#899(PR #1060,2026-08-22 合并)已把同步拆成两段:没有推送权限的候选工作流合并上游、跑全部守卫与引擎冒烟,都通过才产出不可变的提交包;另一个工作流只在候选成功后运行,不执行任何上游代码,核对提交哈希与清单一致后才配置推送凭据并推送。验收前按裁决改写两条、删一条:AC3 去掉 GitHub App 短时令牌与人工审批(现为候选成功后自动推送,PAT 只在推送步骤出现);AC5 改为与 ADR-035/038 一致(新增文件放行);AC6 恶意样本演练删除。AC2 与 AC7 按 owner 选定的「按现状验收」如实记录交付形态,缺口写在下表。

AC	结论	证据
AC1	PASS	.github/workflows/sync-upstream.yml:37-38 permissions: contents: read;文件内两处 actions/checkout 均为 persist-credentials: false(:58 等);全文件零处引用 secrets.SYNC_TOKEN
AC2	按现状验收	候选产物 = git bundle(本次同步新增的全部提交对象,可用 git diff 复原完整 diff 与文件状态)+ manifest.env(dev / alpha 前后提交哈希)(sync-upstream.yml:246-272);只在全部守卫与冒烟通过后产出,检查结果在候选 run 日志里。缺口:没有单独渲染的 diff 文本,检查结果不随产物打包,产物保留 1 天(:280)
AC3	PASS(改写后)	.github/workflows/sync-upstream-push.yml:19-20 workflow_run、:39 conclusion == 'success';:47 checkout 不持久凭据;:80-92 解包出的提交须逐字等于清单哈希;:106-111 推送凭据只在该步配置;全文件不跑 bun install 或任何上游代码
AC4	PASS	sync-upstream.yml:237-240 引擎冒烟排在 :246 产出提交包之前,任一步失败即不产出;推送工作流只在候选 success 时运行(sync-upstream-push.yml:39)
AC5	PASS(改写后)	scripts/north-star-guard.sh:344、:347 --no-renames --diff-filter=DMR;packages/ui-mac/src/main/north-star-guard.test.ts:316-320 钉住「新增文件不点名」(ADR-035/038);登记于 scripts/gate-files.tsv:155
AC6	已删除	需先造演练装置;「上游代码偷推送权限」已由两段工作流结构性隔离
AC7	按现状验收	推送步骤摘要记录候选 run id 与 dev / alpha 前后哈希(sync-upstream-push.yml:116-130),候选摘要同样记录前后哈希(sync-upstream.yml:265-272);凭据只经 env 注入、不回显(sync-upstream-push.yml:106-111)。缺口:AC3 改写后没有人工审批环节(放行依据是候选 run 成功,可按 run id 追溯),不单独记录令牌身份

坐标于 2026-09-17 在 alpha-code origin/alpha @ 8eb092b73 上核对仍然成立。