8000 tree, typescript: declare provenance so the scan has an identity to query by bryan-minimal · Pull Request #741 · gominimal/pkgs · GitHub
[go: up one dir, main page]

Skip to content

tree, typescript: declare provenance so the scan has an identity to query - #741

Merged
bryan-minimal merged 1 commit into
mainfrom
coverage-provenance-tree-typescript
Sep 23, 2026
Merged

bryan-minimal merged 1 commit into
mainfrom
coverage-provenance-tree-typescript

Conversation

@bryan-minimal
@bryan-minimal bryan-minimal commented Sep 22, 2026 •
Copy link
Copy Markdown
Member

Fixes two of the three packages that failed the 2026-09-22 coverage gate (exit(1)):

↑ NEW dark since baseline:        tree
↑ NEW no-cpe-hole since baseline: typescript, which

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 gap

No source_provenance at all, so no vuln query ran: it reported 0/0/0 for an
infrastructural reason, not 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 — same shape psmisc
uses.

typescript — real fix, but not for the obvious reason

You'd expect a project this popular to have advisories. It doesn't, and I checked four
independent sources rather than trusting our corpus:

source advisories
OSV.dev pkg:npm/typescript 0
GitHub advisories on microsoft/TypeScript 0
Debian security tracker node-typescript not tracked
our DB 1 — the Visual Studio one, see below

Peers 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-hole only fires for CPE-sole-scanned packages — 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. That is exactly why
prettier, with the same zero advisories, was never flagged.

Deliberately no 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 false-positive
class we know from glibc.

which — no change, and that is the finding

It already has GnuProject provenance and is queried correctly. The GNU purl arm
works fine — pkg:generic/gnu/binutils has 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.

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 amd64 evaluates the full catalog and both packages resolve
their new provenance:

tree        v=2.3.2   Gitlab{gitlab.com, OldManProgrammer, unix-tree}
typescript  v=7.0.2   GithubRepo{microsoft, TypeScript}
which       v=2.25    GnuProject{which}   (unchanged)

🤖 Generated with Claude Code

Summary by CodeRabbit

  • Chores
    • Added source provenance metadata for the tree package, linking version 2.3.2 to its GitLab repository.
    • Added source provenance metadata for the npm-installed TypeScript package, linking version 7.0.2 to the official Microsoft GitHub repository.
    • Improved package identification and software supply-chain traceability.

…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>
@bryan-minimal
bryan-minimal requested a review from a team as a code owner September 22, 2026 15:44
@coderabbitai
coderabbitai Bot commented Sep 22, 2026 •
Copy link
Copy Markdown
Contributor

Review in Change Stack →

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 configuration

Configuration used: Repository: gominimal/pkgs/.coderabbit.yaml

Review profile: CHILL

Plan: Essentials

Run ID: 2f70dcf9-3fa4-4d7a-8ea6-1a316bd78bf1

📥 Commits

Reviewing files that changed from the base of the PR and between 3dd782f and 60a000c.

📒 Files selected for processing (2)
  • packages/tree/build.ncl
  • packages/typescript/build.ncl

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.


📝 Walkthrough

Walkthrough

The 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.

Changes

Package source provenance

Layer / File(s) Summary
Add upstream repository provenance
packages/tree/build.ncl, packages/typescript/build.ncl
The tree package identifies its GitLab unix-tree source. The TypeScript package identifies the GitHub microsoft/TypeScript source and retains no CPE remapping for the Visual Studio advisory.

Priority: ⬇️ Low

Estimated code review effort: 1 (Trivial) | ~5 minutes

Change: Feature

Merge Risk: ⚪ Minimal · up to 60a00

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)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately identifies the two packages and the main change: adding provenance so scans can query their package identities. It is concise and specific.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Commit to this branch
  • Create a new PR

Comment @coderabbitai help to get the list of available commands.

@bryan-minimal
bryan-minimal added this pull request to the merge queue Sep 23, 2026
Merged via the queue into main with commit 3cfabce Sep 23, 2026
11 checks passed
@bryan-minimal
bryan-minimal deleted the coverage-provenance-tree-typescript branch September 23, 2026 23:58
evanspearman pushed a commit to evanspearman/pkgs that referenced this pull request Oct 20, 2026
…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>
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

0