Repository navigation
Validate Package Dependencies 在 main 上全仓变红:nanoid 3.3.16 命中 GHSA-2v37-7h3g-55p8(有 fix,缺 override) #6506
Description
Activity
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
- marked security: nanoid 3.3.16 命中 GHSA-2v37-7h3g-55p8（CVSS 8.2 High），OSV 门对每个 open PR 变红 #6529 as a duplicate of this issue
on Aug 8, 2026
范围外发现,来自 #6277 / PR #6502 的 CI。不是该 PR 引入的,证据在下面。
事实
Validate Package Dependencies的 OSV-Scanner 步骤在 PR #6502 上 exit 1:为什么这是全仓状态,不是某个 PR 的问题
nanoid@3.3.16在origin/main的pnpm-lock.yaml里逐字相同(main:7403 / 14106;PR 分支:7406 / 14109 —— 只是被上面 3 行 workspace link 顶下去了)。pnpm-lock.yaml的全部改动就是这 3 行(给 plugin-security 加一条 workspace devDependency 的 link),不涉及任何版本变化。--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 那种一上线就自失效的写法)。形如: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 没拦住合并」的另一半问题;这条是让它红的具体原因,值得单独修掉而不是等它自己消失。