Repository navigation
tree, typescript: declare provenance so the scan has an identity to query - #741
Conversation
…uery The 2026-09-22 coverage gate failed the runner (exit 1) with three NEW no-coverage packages since baseline: tree (dark), typescript and which (no-cpe-hole). All three arrived in #721 — they are newly-added packages that were never scannable, not packages that regressed. Two are fixed here. The third is a true negative; see below. ## tree — a genuine gap No source_provenance at all, so NO vuln query ran: it reported 0/0/0 for an infrastructural reason rather than because it is clean. Upstream is `unix-tree` on gitlab.com (our tarball is unix-tree-2.3.2.tar.gz) and tag 2.3.2 there matches what we ship. Uses the Gitlab category with `host`, since GitLab is federated and the same owner/repo on two instances are different projects — the same shape psmisc uses. ## typescript — real fix, but not for the reason it looks like Points at the upstream repo, which is what every other npm-installed package here does (prettier -> prettier/prettier, dotenvx -> dotenvx/dotenvx, opencode -> anomalyco/opencode). Tag v7.0.2 upstream matches what we ship. What this does NOT do is find advisories, because there are none: OSV.dev pkg:npm/typescript ............ 0 GitHub advisories microsoft/TypeScript 0 Debian security tracker node-typescript not tracked peers: eslint 0, prettier 0, webpack 4 Build-time tooling has essentially no CVEs — a compiler consumes trusted input and has no privileged runtime parsing, where webpack's 4 come from its dev-server's network surface. So nobody tracks typescript CVEs, correctly. The flag clears anyway, for the right reason: `no-cpe-hole` only fires for CPE-SOLE-scanned packages, i.e. those with no provenance that fall back to CPE matching. Provenance moves typescript onto the purl arm, where a zero is recorded as a clean query instead of a coverage hole — exactly why prettier, with the same zero advisories, was never flagged. Deliberately NOT adding a cpe_remap for (microsoft, typescript). The only advisory under that pair is CVE-2020-1416, "elevation of privilege in Visual Studio and Visual Studio Code when they load software dependencies", which also names visual_studio_2017/2019/code and carries NO version bounds. Mapping it would attach a 2020 IDE bug to the compiler permanently, with no version that could ever clear it — the unbounded-CPE FP class (cf. glibc). ## which — no change, it is a true negative Already has GnuProject provenance and IS queried correctly: the GNU purl arm works (pkg:generic/gnu/binutils 288 advisories, glibc 166, gnutls 75). `pkg:generic/gnu/which` returns 0 because GNU which has no advisories anywhere. Inventing an identity for it would be fabricating coverage. Verified: `mip dump --packages --arch amd64` evaluates the full catalog and both packages resolve their new provenance. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository: gominimal/pkgs/.coderabbit.yaml Review profile: CHILL Plan: Essentials Run ID: 📒 Files selected for processing (2)
Included review availability: 0 reviews are currently available. Your included PR review attempts over the past 7 days set your current allowance at 1 review per hour. 📝 WalkthroughWalkthroughThe package build declarations now include upstream source provenance for tree version 2.3.2 and TypeScript version 7.0.2. The TypeScript declaration also documents the absence of a CPE remapping. ChangesPackage source provenance
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Feature Merge Risk: ⚪ Minimal · up to This change adds queryable source metadata without identified runtime or deployment impact and is ready to merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…e stale shim (gominimal#761) * ci(node-runtime-guard): evaluate with the runner's pinned mip, not the stale shim Every PR's guard has failed since gominimal#741 merged (2026-09-23 23:58) in "Dump catalog": error: contract broken by a value / failed to validate source_provenance packages/tree/build.ncl:61 category = 'Gitlab The recipe is valid. The public shim's cli pointer (gs://minimal-shim/config/cli-*-linux.json) has said 422f245 (2026-05-28, "this is 0.4.1") since May, and that predates 'Gitlab provenance (minimal d06a77db, 07-14). So CI evaluated with 7FCB a four-month-old minimal, and the guard correctly failed closed on a catalog it could not read. New composite action .github/actions/setup-mip: fetch the public minimalone-25d38aaa archive, sha256-verify the archive and then the extracted mip-linux-amd64, cache it, and put it on PATH. That mip is byte-identical to the pkgsec runner's pinned evaluator (MIP_SHA256 2c5e01cd...a1ed), so the guard and production now evaluate the catalog with the same binary. The binary hash is re-checked on every run, cache hit or not. The guard's dump step now uses `mip dump`. The other report-only workflows still use the shim and should move to setup-mip too (follow-up). Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * ci: evaluate version-age and stable-closure-check with the pinned mip Both report-only jobs used setup-minimal, i.e. the public shim's stale minimal (422f245), whose `minimal dump` fails on current stdlib features. They stayed green by design, so the failure was invisible: version-age warned and no-op'd on an empty dump, stable-closure-check printed UNVERIFIED under --no-fail. Switch both to setup-mip (the runner's sha256-verified 25d38aaa) with identical dump arguments; report-only semantics are unchanged. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> * ci: drop the unused setup-minimal action; name the evaluator in version-age's summary setup-minimal resolved to the public shim's stale 422f245 build. No workflow uses it after this PR, and leaving it around invites copying it into a new one. version-age's step summary still said "minimal dump" after the job moved to mip, so point triage at the right tool. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Fixes two of the three packages that failed the 2026-09-22 coverage gate (
exit(1)):All three arrived in #721 — they are newly-added packages that were never scannable,
not packages that regressed. That is the gate working as designed.
tree— a genuine gapNo
source_provenanceat all, so no vuln query ran: it reported 0/0/0 for aninfrastructural reason, not because it is clean. Upstream is
unix-treeon gitlab.com(our tarball is
unix-tree-2.3.2.tar.gz) and tag2.3.2there matches what we ship.Uses the
Gitlabcategory withhost, since GitLab is federated — same shape psmiscuses.
typescript— real fix, but not for the obvious reasonYou'd expect a project this popular to have advisories. It doesn't, and I checked four
independent sources rather than trusting our corpus:
pkg:npm/typescriptnode-typescriptPeers confirm the pattern: eslint 0, prettier 0, webpack 4. Build-time tooling has
essentially no CVEs — a compiler consumes trusted input and has no privileged runtime
parsing, where webpack's 4 come from its dev-server's network surface.
So the flag is not telling us we're missing data. It clears anyway, for the right
reason:
no-cpe-holeonly fires for CPE-sole-scanned packages — those with noprovenance that fall back to CPE matching. Provenance moves typescript onto the purl arm,
where a zero is recorded as a clean query instead of a coverage hole. That is exactly why
prettier, with the same zero advisories, was never flagged.
Deliberately no
cpe_remapfor (microsoft, typescript). The only advisory under thatpair is
CVE-2020-1416— "elevation of privilege in Visual Studio and Visual Studio Codewhen they load software dependencies" — which also names
visual_studio_2017/2019/codeand carries no version bounds. Mapping it would attach a 2020 IDE bug to the compiler
permanently, with no version that could ever clear it: the unbounded-CPE false-positive
class we know from glibc.
which— no change, and that is the findingIt already has
GnuProjectprovenance and is queried correctly. The GNU purl armworks fine —
pkg:generic/gnu/binutilshas 288 advisories, glibc 166, gnutls 75.pkg:generic/gnu/whichreturns 0 because GNU which has no advisories anywhere.Inventing an identity for it would be fabricating coverage.
Which exposes a real limitation worth its own issue: the gate cannot distinguish "no
advisories exist upstream" from "we failed to map", so it reports true negatives as
coverage holes. Two of the three packages it flagged today are in that category.
Verification
mip dump --packages --arch amd64evaluates the full catalog and both packages resolvetheir new provenance:
🤖 Generated with Claude Code
Summary by CodeRabbit
treepackage, linking version 2.3.2 to its GitLab repository.