fix(deps): raise override floors to clear 3 High advisories (nanoid, js-yaml, undici) - #146
fix(deps): raise override floors to clear 3 High advisories (nanoid, js-yaml, undici)#146lukaso-bot wants to merge 1 commit into
Conversation
New advisories flagged three transitive packages already in main's lockfile, so `osv dependency scan` went red on main and on every open PR without any code change: nanoid 3.3.16 → 3.3.18 GHSA-2v37-7h3g-55p8 CVSS 8.2 js-yaml 4.3.0 → 4.3.1 GHSA-5p4m-2wfm-xmqj CVSS 7.5 undici 7.28.0 → 7.29.0 GHSA-4cwx-7wf7-3272 CVSS 7.4 None is a direct dependency, so this raises the `pnpm.overrides` floors the same way 9b6080a did. `nanoid@3` is keyed to the 3.x range so the override can't pull a major; `jsdom>undici` keeps its `<8` bound, which jsdom 29 needs to collect. osv-check.sh before: 0 Critical + 3 High → exit 1. After: 0 High/Critical, only the four hono 4.12.32 Mediums remain (Dependabot #142 bumps hono; Mediums do not gate). Closes #145
|
Merge this one first. Ordering matters here and it isn't visible from the PR list.
The four "green" rollups are green because their last osv run predates the advisories, not So:
Worth noting separately: main is running the vulnerable versions right now. The last deploy The 4 remaining |
|
Re-verified today against current OSV data, since this PR's CI green is from 17 Aug Scanning this branch's lockfile now: Still 0 High / 0 Critical, so the gate passes. The three Highs this PR targets Branch is also still current with |
Superseded by #138 — closing without mergeThe override floors this PR exists to add are already on and Merging this now would be actively harmful: the only content left in Closing. #145 is fixed and closed too. |
Fixes #145.
osv dependency scanis red on main's untouched lockfile — new advisorieswere published against three packages that were already there, so every open PR
(#138, #139, #141, #142, #144) fails that job without having changed anything.
What this does
Raises three
pnpm.overridesfloors, the same mechanism 9b6080a used:nanoidjs-yamlundiciNone is a direct dependency — all three are transitive, which is why Dependabot
does not offer them.
Two constraints kept intact:
nanoid@3is keyed to the 3.x range, not a barenanoid: ">=3.3.18", sothe override cannot pull nanoid 5.x into a consumer expecting 3.x.
jsdom>undicikeeps its<8upper bound (>=7.29.0 <8). That pin is why9b6080a exists: jsdom 29 does not collect against undici 8. Confirmed still
true below —
undici@8.9.0remains in the lockfile for its other consumer,exactly as on main, so this is not a major bump.
Evidence — the gate red before, green after
The guard here is
scripts/osv-check.shitself, and it was already observedfailing on the real defect. Run on this branch's parent (
39a72d06, main):Same command on this branch:
All 5 undici findings plus js-yaml and nanoid are gone. The four remaining are
hono 4.12.32 Mediums, which do not gate and which #142 bumps (4.13.1).
Gate
Full local gate green on this branch, after
pnpm -r build:pnpm lint— 110 files, no fixespnpm -r typecheck— core / cli / web / web-og all Donepnpm -r test— web 277 passed / 6 skipped, cli 45, web-og 27 + 6 workerspnpm -r build— cleanThe jsdom-collects risk is the one that mattered and it is covered: the
websuite (which uses jsdom 29) passes on undici 7.29.0.
Scope
Deliberately just the lockfile floors. It is not folded into #144 (the
/internal/*cache fix) so the security bump can be reviewed and merged on itsown, without waiting on that PR's review — main is running the vulnerable
versions until something merges and
release.ymlredeploys.Note
scripts/validate.shruns osv warn-only locally (|| true), so this wasonly ever visible at the CI gate.