拆自 #4945 的建议 2。#4945 本身(brace-expansion 5.0.8 到 5.0.9)已由 PR #4961 修掉,合并后该 issue 会关闭,这条设计问题会跟着一起被埋掉,所以单独记录。未认领。
问题
.github/workflows/validate-deps.yml 的 OSV-Scanner step 对任意严重级别的 advisory 一律 exit 1。当命中的 advisory 有修复版本时,这个行为完全正确 —— #4945 就是这样在 10 分钟内被清掉的。
但当一条 advisory 没有可用修复版本时(上游还没发补丁,或者补丁只在一个我们暂时吃不下的 major 里),同样的行为会把一个必跑 job 无限期钉红。而一个长期红的必跑检查,和没有扫描是等价的:所有人都学会跳过它,下一条真正可修的 advisory 在 PR 列表里长得和它一模一样。
这不是假设。pnpm-workspace.yaml 的 overrides 注释里已经记着好几处上游没有稳定修复版本的情形,现在是靠 pre-release pin 顶住的(better-auth 家族的 1.7.0-rc.2、@better-auth/scim 的 1.7.0-rc.1),而 pre-release pin 并不总是存在。
已有机制
workflow 注释指出现成的出口是 osv-scanner.toml 的 [[IgnoredVulns]]:
# Note: OSV-Scanner blocks on any severity, not just high/critical. To
# accept a specific advisory, add an osv-scanner.toml [[IgnoredVulns]]
# entry rather than lowering the gate.
但仓库里目前没有 osv-scanner.toml,所以这条路径一次也没走过,也就没有约定:谁有权加豁免、要写什么理由、expires 该设多久、到期后由谁复核。
需要决定的
- 豁免走
[[IgnoredVulns]] 是否就是最终形态,还是要像 overrides 那样配一个带理由的注释块 + 一个 check 脚本(参考 check-override-consistency.mjs 的做法)来强制每条豁免必须写明:advisory id、为什么现在修不了、复核日期。
expires 是否强制。一条永不过期的豁免,和今天这条永远红的 job 是同一个失败模式,只是方向相反 —— 前者静默,后者吵闹,都让人不再看。- 定期扫描(该 workflow 已有 weekly cron)在豁免到期时应该怎么提醒 —— 该 job 已有
issues: write 权限,自动开 issue 是现成可用的。
倾向:豁免必须带 expires 且必须带理由,由一个 self-test 过的 check 脚本强制,与 overrides 块的现有风格保持一致 —— 但这属于会长期约束他人的流程决定,留给维护者定,不要 agent 自行猜。
拆自 #4945 的建议 2。#4945 本身(brace-expansion 5.0.8 到 5.0.9)已由 PR #4961 修掉,合并后该 issue 会关闭,这条设计问题会跟着一起被埋掉,所以单独记录。未认领。
问题
.github/workflows/validate-deps.yml的 OSV-Scanner step 对任意严重级别的 advisory 一律 exit 1。当命中的 advisory 有修复版本时,这个行为完全正确 —— #4945 就是这样在 10 分钟内被清掉的。但当一条 advisory 没有可用修复版本时(上游还没发补丁,或者补丁只在一个我们暂时吃不下的 major 里),同样的行为会把一个必跑 job 无限期钉红。而一个长期红的必跑检查,和没有扫描是等价的:所有人都学会跳过它,下一条真正可修的 advisory 在 PR 列表里长得和它一模一样。
这不是假设。
pnpm-workspace.yaml的 overrides 注释里已经记着好几处上游没有稳定修复版本的情形,现在是靠 pre-release pin 顶住的(better-auth 家族的1.7.0-rc.2、@better-auth/scim的1.7.0-rc.1),而 pre-release pin 并不总是存在。已有机制
workflow 注释指出现成的出口是
osv-scanner.toml的[[IgnoredVulns]]:但仓库里目前没有
osv-scanner.toml,所以这条路径一次也没走过,也就没有约定:谁有权加豁免、要写什么理由、expires该设多久、到期后由谁复核。需要决定的
[[IgnoredVulns]]是否就是最终形态,还是要像 overrides 那样配一个带理由的注释块 + 一个 check 脚本(参考check-override-consistency.mjs的做法)来强制每条豁免必须写明:advisory id、为什么现在修不了、复核日期。expires是否强制。一条永不过期的豁免,和今天这条永远红的 job 是同一个失败模式,只是方向相反 —— 前者静默,后者吵闹,都让人不再看。issues: write权限,自动开 issue 是现成可用的。倾向:豁免必须带
expires且必须带理由,由一个 self-test 过的 check 脚本强制,与 overrides 块的现有风格保持一致 —— 但这属于会长期约束他人的流程决定,留给维护者定,不要 agent 自行猜。