fix(deps): close the undici, fast-uri, postcss and brace-expansion advisories #55
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: unom/punktfunk#55
Reference in New Issue
Block a user
Turns
audit.yml's three blockingbun-auditlegs green. Merge this before cutting v0.25.0 — it is one of the two reds standing between main and a clean tag.10 findings each in
sdkandplugin-kit, 8 inweb. Every one is a transitive dependency; none was fixable by bumping a direct dep.web — stale pins in a mechanism that already existed
webalready carried anoverridesblock whoseundiciandfast-uripins had simply gone stale, so this is four bumps rather than a new idea:undici^7.28.0^7.29.0>=7.0.0 <7.29.0)fast-uri^3.1.4^3.1.5>=3.0.0 <3.1.5)postcss^8.5.10^8.5.25brace-expansion^5.0.8^5.0.9The last two were not in the red run but would have taken the next audit red anyway. All four stay inside their current major.
sdk / plugin-kit — why the fix looks the way it does
The single finding is
undici8.7.0/8.8.0 pulled in by@effect/platform-node, a devDependency pinned at4.0.0-beta.98. That package already declaresundici: ^8.7.0, which permits the fixed 8.10.0 — the vulnerable version survives purely as a stale lockfile resolution.Nothing bumps it in place:
bun updateonly walks direct dependencies.bun install --forcepreserves a resolution that still satisfies its range.@effect/platform-noderelease throughbeta.103declares the same^8.7.0, so moving the dep changes nothing.warn: Bun currently does not support nested "resolutions".So a flat
overridesentry is the only mechanism available, and it necessarily also moves sdk's top-level undici from 7.x to 8.x.That was verified, not assumed. The only source use is
sdk/src/config.ts, which doesnew Agent({ connect: { ca } })behind a dynamic import and atry/catchwith a documented plain-fetchfallback;Agentand itsconnectoption are unchanged between undici 7 and 8. Both trees now dedupe to a single undici 8.10.0.Consumers are deliberately untouched.
overridesapply only at the root of the tree that declares them and are not honored when the package is installed as a dependency, so sdk's publishedoptionalDependencies: { undici: "^7.0.0" }is left alone — a consumer resolves the latest 7.x, which is the fixed 7.29.0. The override governs this repo's own tree, which is exactly whataudit.ymlchecks. Worth knowing: sdk's dev tree therefore exercises undici 8 while consumers get 7.Two traps found on the way
A malformed lockfile that disguises itself as a tooling error. Running
bun installover plugin-kit's existing lockfile emitted two byte-identical@punktfunk/hostentries — itsfile:../sdkdependency crossed with the new override — and bun then refuses its own output withError loading lockfile: InvalidPackageKey. That reads as a broken toolchain rather than a finding, so it would have taken the gate down while looking like something else entirely. Regenerating the lockfile from scratch produces a valid single entry; all three lockfiles were checked for duplicate keys.A vacuous green that was rejected. Deleting the pinned nested entry from a lockfile makes
bun auditreportNo vulnerabilities foundwhile the vulnerable copy is still installed on disk —bun auditreads the lockfile, notnode_modules. Recorded here because it is convincing and wrong.Verification
bun auditclean in all three trees.webbuilds and typechecks (its typecheck needs the build first, which generatesrouteTree.gen).sdktypechecks, 72/72 tests pass against undici 8.10.0.plugin-kittypechecks, 20/20 tests pass.Not addressed here
The other red on main is
ci.yml's Linuxrustjob failing withNo space left on device— the runner is out of disk, unrelated to this change and still outstanding.audit.yml's three blocking bun-audit legs (web, sdk, plugin-kit) were all red on main. Ten findings in sdk and plugin-kit, eight in web; every one of them a transitive dependency, none reachable by bumping a direct dep. web already carried the right mechanism — an `overrides` block whose `undici` and `fast-uri` pins had simply gone stale — so it needed four bumps, not a new idea: undici 7.28.0 -> ^7.29.0 and fast-uri 3.1.4 -> ^3.1.5 for the reported advisories, plus postcss ^8.5.10 -> ^8.5.25 and brace-expansion ^5.0.8 -> ^5.0.9 for two more that were published after the failing run and would have gone red on the next audit anyway. All four stay inside their current major. sdk and plugin-kit were harder and the fix deserves an explanation. Their single finding is undici 8.7.0/8.8.0 pulled in by @effect/platform-node, a devDependency pinned at 4.0.0-beta.98. That dependency already declares `undici: ^8.7.0`, which permits the fixed 8.10.0 — the vulnerable version survives purely as a stale lockfile resolution. Nothing bumps it in place: `bun update` only walks direct dependencies, `bun install --force` preserves a resolution that still satisfies its range, and every platform-node release through beta.103 declares the same `^8.7.0`, so moving the dep changes nothing. Bun rejects the scoped form outright ("Bun currently does not support nested resolutions"), so a flat `overrides` entry is the only mechanism available, and it necessarily also moves sdk's top-level undici from 7.x to 8.x. That is safe here, and was verified rather than assumed. The only source use is sdk/src/config.ts, which does `new Agent({ connect: { ca } })` behind a dynamic import and a try/catch with a documented plain-fetch fallback; `Agent` and its `connect` option are unchanged between undici 7 and 8. sdk typechecks and its 72 tests pass against 8.10.0; plugin-kit typechecks and its 20 tests pass. Both trees now dedupe to a single undici 8.10.0. Consumers are deliberately untouched: `overrides` apply only at the root of the tree that declares them and are not honored when the package is installed as a dependency, so sdk's published `optionalDependencies: { undici: "^7.0.0" }` is left alone — a consumer resolves the latest 7.x, which is the fixed 7.29.0. The override governs this repo's own tree, which is exactly what audit.yml checks. Worth knowing: sdk's dev tree therefore exercises undici 8 while consumers get 7. One trap found on the way. Running `bun install` over plugin-kit's existing lockfile emitted a lockfile with two byte-identical `@punktfunk/host` entries — its `file:../sdk` dependency crossed with the new override — and bun then refuses its own output with "Error loading lockfile: InvalidPackageKey". That reads as a tooling error rather than a finding, so it would have taken the audit gate down while looking like something else entirely. Regenerating the lockfile from scratch produces a valid single entry; all three lockfiles are checked for duplicate keys. Also worth recording, because it nearly shipped: deleting the pinned nested entry from a lockfile makes `bun audit` report "No vulnerabilities found" while the vulnerable copy is still installed on disk. bun audit reads the lockfile, not node_modules. That is a vacuous green, not a fix, and was rejected. Verified: `bun audit` clean in all three trees; web builds and typechecks (its typecheck needs the build first, which generates routeTree.gen); sdk 72/72 and plugin-kit 20/20 tests pass.