`Validate Package Dependencies` 在 main 上全仓变红:nanoid 3.3.16 命中 GHSA-2v37-7h3g-55p8(有 fix,缺 override)

[baozhoutao]

范围外发现,来自 #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 没拦住合并」的另一半问题;这条是让它红的具体原因,值得单独修掉而不是等它自己消失。

[os-zhuang]

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) — root pnpm-workspace.yaml overrides block: currently has 'postcss@<9.0.0': '^8.5.10' (line 150) and no nanoid entry, exactly as the body states. nanoid@3.3.16 present in pnpm-lock.yaml at lines 7403 / 14106, pulled in via postcss (line 14405 nanoid: 3.3.16). Root-workspace override + scripts/ gate rerun ⇒ domain:devx per 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 on pnpm-workspace.yaml observed on the current main.

Stale-premise check — passes in full on 3a1d9c7: the vulnerable version is still resolved and the override is still absent, so Validate Package Dependencies stays red for every PR based on current main.

target:v17 rationale — 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