fix(deps): force fast-uri >= 3.1.5 and resync the Flatpak sources - #489
Conversation
fast-uri < 3.1.5 recognises a URI authority only after a literal `//`, so `\\host`, `/\host` and `\/host` fold into the path instead. Node's WHATWG URL treats `\` as interchangeable with `/` for special schemes, so the two parsers disagree on the host of the same input and any host-based policy checked with one and acted on with the other can be steered elsewhere (GHSA, Dependabot #17). It reaches us transitively through @commitlint/cli -> ajv, which asks for ^3.0.1, so an `overrides` entry pinned to ^3.1.5 is enough -- no direct dependency, and it stays inside the 3.x line ajv expects. The override sits in package.json, which is also what the Flatpak lockfile is generated from, so one entry covers bun.lock (which carried the even older 3.1.2 -- Dependabot doesn't parse bun.lock and never flagged it) and packaging/flatpak/generated/package-lock.json. Regenerating the Flatpak sources surfaced a second, unrelated problem: cargo-sources.json was stale. `chore: update dependencies` (23be643) bumped Cargo.lock without re-running generate-sources.sh, leaving 53 crates declared in the lock with no source entry -- wasmtime 46.0.1 vs 47.0.3 among them. Flathub builds with the network disabled, so that build could only fail. After regeneration every crate in Cargo.lock has a source (0 missing) and every package in the npm lockfile has a tarball (0 missing), both verified programmatically. Hence the large diff: the sources catch up on dependency drift that had accumulated since the last regeneration, not just on fast-uri. Claude-Session: https://claude.ai/code/session_01N9WXrurarkoiT2jgimvyj1
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (4)
📒 Files selected for processing (1)
📝 WalkthroughWalkthrough
ChangesConfiguration de dépendance
Estimated code review effort: 1 (Trivial) | ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Billing warning: we have not been able to collect payment for this subscription for more than 72 hours. Please update the payment method or pay any pending invoices in Billing to avoid service interruption. Comment |
|
@coderabbitai review |
✅ Action performedReview finished.
|
Closes Dependabot alert #17.
The vulnerability
fast-uri< 3.1.5 only recognises a URI authority after a literal//, so a reference using\\,/\or\/as the introducer folds the host into the path. Node's WHATWG URL (behindfetch(), undici,http/https) treats\as interchangeable with/for special schemes, so the two parsers extract different hosts from the same input —\\evil.com/pathagainsthttps://allowed.com/giveshttps://allowed.com/%5C%5Cevil.com/pathto one andhttps://evil.com/pathto the other. Anything that validates a host with one parser and fetches with the other can be pointed elsewhere.The fix
It reaches us transitively —
@commitlint/cli→ajv→fast-uri ^3.0.1— so anoverridesentry is enough. Pinned to^3.1.5: patched, and inside the3.xlineajvasks for (>=3.1.5would have allowed 4.x).The override lives in
package.json, which is also what the Flatpak lockfile is generated from, so one entry covers both lockfiles:bun.lock— carriedfast-uri@3.1.2, older than the flagged one. Dependabot doesn't parsebun.lock, so it never flagged the project's actual lockfile. Now3.1.5.packaging/flatpak/generated/package-lock.json— the one in the alert. Now3.1.5.Editing the generated lockfile by hand would have been undone by the next
generate-sources.shrun, and would have leftnode-sources.jsonpointing at the 3.1.4 tarball — so the sources were regenerated with the documented script instead.Why the diff is 15k lines
Regenerating surfaced a separate, pre-existing problem:
cargo-sources.jsonwas stale.chore: update dependencies(23be643) bumpedCargo.lockwithout re-runninggenerate-sources.sh, so 53 crates in the lock had no source entry — including wasmtime46.0.1declared against47.0.3in the lock. Flathub builds with the network disabled, so that build could only fail on a missing crate.Verified programmatically, before and after:
Cargo.lockwith no sourceSo the bulk of the diff is the generated sources catching up on dependency drift accumulated since the last regeneration — not fast-uri.
Checks
bun run typecheck✅ ·bun run lint✅bunx commitlintstill runs on the overriddenfast-uri(it's the consumer, via ajv) ✅Cargo.lockhas a source entry, every package in the npm lockfile has a tarball ✅Not verified by me: an actual
flatpak-builderrun. The consistency checks above are structural — they prove nothing is missing, not that the build succeeds end to end.Worth considering separately: the Flatpak sources drifted because nothing enforces regeneration when
Cargo.lockorpackage.jsonchanges. A CI check that re-runs the generator and fails on a dirty tree would have caught this at 23be643.https://claude.ai/code/session_01N9WXrurarkoiT2jgimvyj1
Summary by CodeRabbit