fix: main's runtime tree carries fast-uri and qs advisories - #866
Merged
Conversation
…and the bundle with it `npm audit --omit=dev --audit-level=low` fails on `main` at 597ac75, not only on the open dependency pull requests. Both findings are in the runtime tree, which is the tree that gets bundled into `dist/commitlore.mjs` and installed: fast-uri 3.1.5 high GHSA-5jgf-p345-68v8, GHSA-f65p-4m7j-42xc, GHSA-fph4-wmhf-6fwf, GHSA-jqff-g426-hqxp (reached through ajv, a direct dependency) qs 6.15.3 moderate GHSA-x5fp-wj9c-mxmx, GHSA-4mjr-xmp4-gh2g (reached through @modelcontextprotocol/sdk -> express) This is why every open dependency pull request is red on `audit` while `check` is green: the advisories were published after those branches last ran, and none of the bumps on them touches either package. Fixing them there would have been three copies of this commit. `npm audit fix` without `--force` was enough: fast-uri 3.1.5 -> 3.1.7, qs 6.15.3 -> 6.16.0, nanoid 3.3.16 -> 3.3.18, nine lines of `package-lock.json` and no edit to `package.json`. Both packages are runtime dependencies and therefore bundled, so the canonical build was mandatory rather than a formality -- the artifact digest moves to 469d61aa6502ebdbdd9915e5b962144bb718b782a634cd43cf19a53f8fde5a5e. Record-Id: r-fasturiqsaudit Follows: r-cdebmanifest Provenance: authored Certainty: firm Blast: system Undo: easy Ruled-out: fixing this on each dependency pull request instead | the advisories are on main, so each branch would carry an identical lockfile and dist change and the three would conflict with each other on merge Ruled-out: npm audit fix --force | it also rewrites the dev tree through breaking upgrades, which is the vitest major question and not a security fix; the five remaining advisories are dev-only and outside what CI's --omit=dev gate asserts Limit: an audit is a claim about advisories published at this moment, not about the code; a clean run says nothing about tomorrow's disclosures Verified: npm audit --omit=dev --audit-level=low reports 0 vulnerabilities on this branch; the pinned linux/amd64 build produced the committed dist and artifact:verify exits 0; typecheck and check-engines clean; 3157 tests passed and 4 skipped across 164 files Unverified: CI has not yet run this branch; the runtime effect of qs 6.16.0 inside express is exercised only as far as this repository's suite reaches it
CommitLore — record lintTrailers: clean — 1 commit in Active constraints for the paths this PR touchesLimits (264)
Ruled out (410)
Truncated: 423 lines omitted — the comment hit GitHub's 65000 character limit. Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
MongLong0214
added a commit
that referenced
this pull request
Sep 7, 2026
…and's `check (24)` failed on #866 with `expected [ …(39) ] to deeply equal [ …(40) ]` in `capture --shadow > runs prepare and verify against history without changing the worktree or .git`. The diff named one entry: - file .git/objects/maintenance.lock e3b0c442...b7852b855 `e3b0c442...b7852b855` is the SHA-256 of the empty string, so the missing entry is an empty lock file that git's auto-maintenance created before the `before` snapshot and removed before the `after` one. Nothing the command did produced or consumed it. The obvious repair -- filter `*.lock` out of `byteSnapshot` -- is the wrong one. That snapshot is exhaustive precisely because it is the evidence that `capture --shadow` is read-only, and a filter is a place a real stray file can hide. So the fixture denies git the background work instead: `gc.auto 0` and `maintenance.auto false` on the temporary repository leave nothing transient for the snapshot to disagree about, and the snapshot stays total. Record-Id: r-shadowsnapshotlock Provenance: authored Certainty: firm Blast: local Undo: easy Ruled-out: filtering lock files out of byteSnapshot | it makes the snapshot non-exhaustive, and the snapshot's exhaustiveness is the whole assertion -- a stray file written by the command would then be able to hide behind the same filter Ruled-out: retrying the flake and moving on | the trigger is git's auto-maintenance heuristic, which fires on repository state rather than on chance, so it returns on the next branch that reaches the same threshold Limit: this fixture only; other suites build repositories through createTestRepo, which does not disable maintenance either, and would show the same shape if any of them ever compared .git byte for byte Verified: test/capture-shadow.test.ts passes 3/3 locally after the change; the failing CI diff named exactly one entry and it was the maintenance lock Unverified: the failure was observed once, on one runner; this removes the mechanism rather than demonstrating the mechanism's absence over repeated runs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
npm audit --omit=dev --audit-level=lowfails onmainat 597ac75, not only on the open dependency PRs. Both findings are in the runtime tree — the one bundled intodist/commitlore.mjsand installed:fast-uri3.1.5ajv(direct dependency)qs6.15.3@modelcontextprotocol/sdk→expressThis is why every open dependency PR is red on
auditwhilecheckis green: the advisories were published after those branches last ran, and none of the bumps on them touches either package. #861, #862, #863 and #864 cannot go green until this lands.What changed
npm audit fix, without--force:fast-uri3.1.5 → 3.1.7qs6.15.3 → 6.16.0nanoid3.3.16 → 3.3.18Nine lines of
package-lock.json;package.jsonis untouched. Both vulnerable packages are runtime dependencies and therefore bundled, so the canonical build was mandatory rather than a formality —dist/commitlore.mjsandinstaller/canonical-artifact.jsonmove with it. The artifact digest becomes469d61aa6502ebdbdd9915e5b962144bb718b782a634cd43cf19a53f8fde5a5e.Verified locally
npm audit --omit=dev --audit-level=low→ 0 vulnerabilitieslinux/amd64canonical build produced the committeddist;artifact:verifyexits 0tsc --noEmitclean,check-enginescleantest/dogfood.test.ts10/10 on this commitNot addressed here
Five dev-only advisories remain and need
npm audit fix --force, which rewrites the dev tree through breaking upgrades. That is the vitest major question (#864), not a security fix, and CI's--omit=devgate does not assert on them.