Repository navigation
Validate Package Dependencies 在 main 上全仓变红:nanoid 3.3.16 命中 GHSA-2v37-7h3g-55p8(有 fix,缺 override) #6506
Description
范围外发现,来自 #6277 / PR #6502 的 CI。不是该 PR 引入的,证据在下面。
事实
Validate Package Dependencies 的 OSV-Scanner 步骤在 PR #6502 上 exit 1:
Total 1 package affected by 1 known vulnerability (0 Critical, 1 High, 0 Medium, 0 Low, 0 Unknown)
1 vulnerability can be fixed.
| OSV URL | CVSS | ECOSYSTEM | PACKAGE | VERSION | FIXED VERSION | SOURCE |
| https://osv.dev/GHSA-2v37-7h3g-55p8 | 8.2 | npm | nanoid | 3.3.16 | 3.3.17 | pnpm-lock.yaml |
为什么这是全仓状态,不是某个 PR 的问题
nanoid@3.3.16在origin/main的pnpm-lock.yaml里逐字相同(main:7403 / 14106;PR 分支:7406 / 14109 —— 只是被上面 3 行 workspace link 顶下去了)。- PR test(plugin-security): feed the VAMA DELETE half a call shape the engine accepts (#6277) #6502 对
pnpm-lock.yaml的全部改动就是这 3 行(给 plugin-security 加一条 workspace devDependency 的 link),不涉及任何版本变化。 - 该 job 扫的是
--lockfile=pnpm-lock.yaml,所以任何基于当前 main 的 PR 都会撞到同一条,直到 main 上修掉。
传入路径:postcss@8.5.25 -> nanoid: 3.3.16(pnpm-lock.yaml:14408)。pnpm-workspace.yaml 的 overrides 里目前没有 nanoid 条目。
修法方向(未在本单实施)
osv-scanner.toml 的头部规矩很明确:advisory 有 fixed version 时走取修复那条路,不进豁免账本(该账本当前是零条目的稳态)。所以这里应当是在 pnpm-workspace.yaml 的 overrides 里加一条 nanoid 的 floor pin,并遵守 #6095 的选择子形状 —— 上界放在大版本边界,不要写成目标自身的版本线(nanoid@<3.3.17 -> ^3.3.17 正是 #4961 / #5032 那种一上线就自失效的写法)。形如:
'nanoid@>=<advisory 的 affected floor> <4.0.0': '^3.3.17'floor 请按 GHSA-2v37-7h3g-55p8 通告里的 affected range 填,不要照抄本文。改完跑 pnpm install + node scripts/check-override-consistency.mjs。
顺带留意 overrides 里已有 'postcss@<9.0.0': '^8.5.10' —— nanoid 是它拖进来的,但 postcss 8.5.25 已经在这条 pin 之上,所以抬 postcss 未必能解决,直接 pin nanoid 更直接。这一点没有实测,只是提醒下一位不要先去动 postcss。
影响
Validate Package Dependencies 是每个 PR 都会跑的 job,现在它在所有 PR 上都是红的。#5617 记录过「红 job 没拦住合并」的另一半问题;这条是让它红的具体原因,值得单独修掉而不是等它自己消失。
Activity
os-zhuang commentedon Aug 8, 2026
Triage:
pm:queue+domain:devx+target:v17.Classification — concrete, scoped tooling/gate fix with a named landing site and a stated fix route (floor-pin override per the #6095 selector shape, then
pnpm install+node scripts/check-override-consistency.mjs). Nothing to ask.Landing site (read on
origin/main@3a1d9c7, not a worktree) — rootpnpm-workspace.yamloverrides block: currently has'postcss@<9.0.0': '^8.5.10'(line 150) and no nanoid entry, exactly as the body states.nanoid@3.3.16present inpnpm-lock.yamlat lines 7403 / 14106, pulled in viapostcss(line 14405nanoid: 3.3.16). Root-workspace override +scripts/gate rerun ⇒domain:devxper the domain table's scripts/gate row.Dedup — repo-scoped search for
nanoid/ the GHSA id: only this card (the other hit, #6277, matches incidentally). No open PR carries a nanoid override fix. Sibling repos: zero nanoid cards in objectui and cloud. Shared-infra check (operational note 8): no in-flight fix onpnpm-workspace.yamlobserved on the current main.Stale-premise check — passes in full on
3a1d9c7: the vulnerable version is still resolved and the override is still absent, soValidate Package Dependenciesstays red for every PR based on current main.target:v17rationale — the OSV gate is red on every PR including any release PR, and shipping an RC with a known-High advisory that has a published fixed version is apology-class release-notes material (criteria ① of the release-board test as it reaches the pipeline, ④ on the shipped artifact). The maintainer may strike; this seat is the label's only producer.Note for the implementing lane — the body's own caution stands: follow the GHSA affected range for the floor, keep the upper bound at the major boundary (avoid the #4961/#5032 self-expiring selector), and do not detour via a postcss raise.
本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code