Skip to content

fix(deps): three security overrides had been overtaken by their own fixes - #916

Open
tobyhede wants to merge 1 commit into
mainfrom
fix/dependency-override-refresh
Open

fix(deps): three security overrides had been overtaken by their own fixes#916
tobyhede wants to merge 1 commit into
mainfrom
fix/dependency-override-refresh

Conversation

@tobyhede

Copy link
Copy Markdown
Contributor

Closes seven open npm Dependabot alerts. Independent of any feature work — extracted from #885/#915 so it is not gated behind a 1000-file review.

Two failure shapes, and the second is worse

An overtaken selector goes quiet. js-yaml@<3.15.0 was overtaken by its own fix: the tree resolved exactly 3.15.0, so nothing matched and nothing lifted it to 3.15.1 (#189). The entry sits there looking like a fix while the vulnerable version installs underneath it.

An exact pin inside a still-matching range enforces the vulnerability. js-yaml@>=4.0.0 <5 kept matching, so a pin written to fix an advisory was holding the tree at 4.2.0 and blocking 4.3.1 (#155, #188). fast-uri@<3.1.3 did the same at 3.1.3 while #158 needs 3.1.4 and #175 needs 3.1.5. This shape cannot self-heal and Dependabot cannot fix it either — the override wins.

Both are now written into the comments, because the lesson is reusable: keep the ceiling ahead of the patched floor, not at it. The postcss entry already had that treatment and needed no change.

Override Was Now
js-yaml 3.x <3.15.03.15.0 <3.15.13.15.1
js-yaml 4.x >=4.0.0 <54.2.0 >=4.0.0 <54.3.1
fast-uri <3.1.33.1.3 <3.1.53.1.5
brace-expansion <5.0.7^5.0.7

Resolved: js-yaml@3.15.1, js-yaml@4.3.1, fast-uri@3.1.5, brace-expansion@5.0.9.

The js-yaml caution is discharged, not ignored

The old comment warned that a past js-yaml bump broke changesets. Checked rather than assumed:

  • @changesets/parse@0.4.3 declares js-yaml: ^4.1.1, which 4.3.1 satisfies — and it resolves 4.3.1 at its own path, verified, not a nested copy
  • 4.2.0 and 4.3.1 have identical dependencies and exports, no engines, no main
  • 4.3.0/4.3.1 are security backports only; the breaking churn (grouped constant exports, MERGE_KEY removal, mandatory identify) is all on 5.x, which the <5 ceiling excludes
  • pnpm exec changeset status parses every changeset and produces the correct per-package bumps

No cooldown bypass needed — every target is 13–70 days old against the 7-day minimumReleaseAge. The comment claiming "4.3.0 is still inside the cooldown" was 54 days stale.

Verification

code:check 0 · test:scripts green · supply-chain.e2e.test.ts 25 passed · changeset status correct

Deliberately not here

  • sharp (chore(deps): bump vite from 6.3.5 to 6.4.1 #191) wants 0.34.5 → 0.35.0 — a minor on a 0.x native module, breaking by convention. It needs its own exercised build, not a ride-along with lockfile hygiene.
  • jsonwebtoken is the Rust alert in packages/protect-ffi/Cargo.lock, blocked by an exact stack-auth = \"=0.42.0\" pin in that crate's manifest — a manifest change, not a lockfile refresh.

No changeset: none of these is a runtime dependency of any published package.

Seven open HIGH/MEDIUM npm alerts, all reachable because the overrides
written to close earlier advisories had gone stale in two distinct ways.

OVERTAKEN SELECTORS go quiet. `js-yaml@<3.15.0` was overtaken by its own
fix — the tree resolved exactly 3.15.0, so nothing matched and nothing
lifted it to 3.15.1 (#189).

EXACT PINS INSIDE A STILL-MATCHING RANGE are worse: they cannot self-heal,
and Dependabot cannot fix them either. `js-yaml@>=4.0.0 <5` kept matching,
so a pin written to FIX an advisory was holding the tree at 4.2.0 and
blocking 4.3.1 (#155, #188 — quadratic-CPU DoS via merge-key chains, then
`!!omap` duplicate-key detection). `fast-uri@<3.1.3` did the same at 3.1.3
while #158 needs 3.1.4 and #175 needs 3.1.5.

Both shapes are now written into the comments, because the lesson is
reusable: keep the ceiling AHEAD of the patched floor rather than at it.
The `postcss` entry already had this treatment and needed no change.

THE js-yaml CAUTION IS DISCHARGED, checked rather than assumed. The comment
warned that a past bump broke changesets. @changesets/parse declares
`js-yaml: ^4.1.1`, which 4.3.1 satisfies; 4.2.0 and 4.3.1 have identical
`dependencies` and `exports`, no `engines`, no `main`; 4.3.0 and 4.3.1 are
security backports only, with no API removal on the 4.x line — the breaking
churn (grouped constant exports, MERGE_KEY removal, mandatory identify) is
all on 5.x, which the `<5` ceiling already excludes. Verified by resolving
js-yaml from @changesets/parse's own path and running `changeset status`,
which parsed every changeset and produced the correct per-package bumps.

brace-expansion (#190) is added rather than repaired — a transitive patch
bump with no prior entry.

No cooldown bypass was needed: every target is 13-70 days old against the
7-day minimumReleaseAge. The comment claiming "4.3.0 is still inside the
cooldown" was 54 days stale.

None of these is a runtime dependency of any published package, so nothing
ships them and this needs no changeset.

NOT FIXED HERE, deliberately: `sharp` (#191) wants 0.34.5 -> 0.35.0, a minor
on a 0.x native module and therefore breaking by convention — it needs its
own exercised build rather than riding along with lockfile hygiene. The
`jsonwebtoken` alert is Rust, in packages/protect-ffi/Cargo.lock, and is
blocked by an exact `stack-auth = "=0.42.0"` pin in that crate's manifest,
so it is a manifest change rather than a lockfile refresh.
@tobyhede
tobyhede requested a review from a team as a code owner August 19, 2026 02:46
@changeset-bot

changeset-bot Bot commented Aug 19, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 447d1a0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants