Skip to content

charon-ml, aeneas: declare GithubRepo provenance — both were UNSCANNED - #574

Draft
bryan-minimal wants to merge 1 commit into
mainfrom
bryan/gitlab-provenance-backfill
Draft

charon-ml, aeneas: declare GithubRepo provenance — both were UNSCANNED#574
bryan-minimal wants to merge 1 commit into
mainfrom
bryan/gitlab-provenance-backfill

Conversation

@bryan-minimal

Copy link
Copy Markdown
Member

The nightly scan's second warning line — the one below the CPE-coverage line I've been chasing — reports:

35 package(s) emitted NO vuln query (no OSV ecosystem, no GitHub repo, not GnuProject/Sourceforge) — UNSCANNED, reported as 0 findings

That's a strictly worse class than "queried, found nothing": these were never asked. charon-ml and aeneas are on that list, and both have a plain GitHub upstream that simply was never declared.

package upstream license
charon-ml AeneasVerif/charon Apache-2.0 (confirmed via API)
aeneas AeneasVerif/aeneas Apache-2.0 (confirmed via API)

Both sources are gs://-mirrored, and Provenance::from_url deliberately declines gs:// — so nothing could infer these; they had to be declared.

Neither resolves any advisory today (OSV GIT query returns 0 for both repos, checked). That's the point — a queried zero is an answer, an unqueried zero is not. From here they ride the OSV GIT / GHSA path like every other GithubRepo package.

Verified with pkgmgr check-onboarding against this branch: 80 gaps → 78, and neither package appears in the output any more.


The other three couldn't be fixed, and the reason is the interesting part

menhir, visitors and unionfind are also on the unscanned list. All three are fpottier projects on gitlab.inria.fr, and each build.ncl header already says so:

"no Gitlab provenance category yet — minimal-supply-chain#347"

That category has since shipped on the tooling side (sc#347/#348 + pm#511): Provenance::Gitlab { host, owner, repo } exists in the Rust parser and scan.rs routes it. But the minimal stdlib contract never got it. From attr_classes.ncl in the stdlib actually in use, the accepted set is exactly:

'GithubRepo   'GnuProject   'Sourceforge   'Website

Declaring 'Gitlab under | Attrs fails the contract outright — and not gracefully. minimal dump aborts with failed to validate source_provenance and the whole package set fails to evaluate, not just that package. I hit exactly this and it silently turned a check-onboarding run into "0 packages evaluated successfully", which reads as a pass.

psmisc looks like a counter-example. It isn't.

psmisc ships category = 'Gitlab on main today — but its attrs block carries no | Attrs annotation, so it is never contract-checked. That's an accident rather than a pattern to copy, and it means we currently have one package whose provenance the contract has never validated.

So the pkgs half wasn't forgotten — it wasn't expressible

Raising the stdlib gap is a minimal-side decision, so this PR stops at the two packages that can land today rather than working around a contract. Flagging it here so the next person doesn't rediscover it the same way.

Remaining on the unscanned list after this: 33, including the X11 stack (libdrm, xorgproto, xtrans, xcb-proto, libxau, libx*, atk, at-spi2-core), ghc/ghc-bootstrap, and several vendor CLIs.

The nightly scan's second warning line (below the CPE-coverage one) reports:

    ⚠ 35 package(s) emitted NO vuln query (no OSV ecosystem, no GitHub repo,
      not GnuProject/Sourceforge) — UNSCANNED, reported as 0 findings

That is a strictly worse class than "queried, found nothing": these packages
were never asked. charon-ml and aeneas are on that list, and both have a plain
GitHub upstream that just was never declared.

  charon-ml → AeneasVerif/charon   (Apache-2.0, confirmed via API)
  aeneas    → AeneasVerif/aeneas   (Apache-2.0, confirmed via API)

Both sources are gs://-mirrored, and `Provenance::from_url` deliberately
declines gs:// — so nothing could infer these; they had to be declared.

Neither currently resolves any advisory (OSV GIT query returns 0 for both
repos, checked today), so this changes no finding today. That is the point: a
queried zero is an answer, an unqueried zero is not. From here they ride the
OSV GIT / GHSA path like every other GithubRepo package.

Verified with `pkgmgr check-onboarding` against this branch: 80 gaps -> 78, and
neither package appears in the output any more.

## The other three could NOT be fixed, and the reason matters

menhir, visitors and unionfind are also on the unscanned list. All three are
fpottier projects on gitlab.inria.fr, and each build.ncl header already says:

    "no `Gitlab` provenance category yet — minimal-supply-chain#347"

That category HAS since shipped on the tooling side (sc#347/#348 + pm#511):
`Provenance::Gitlab { host, owner, repo }` exists in the Rust parser and
scan.rs routes it. But the minimal STDLIB contract never got it. From the
stdlib in use (`attr_classes.ncl`), the accepted set is exactly:

    'GithubRepo   'GnuProject   'Sourceforge   'Website

Declaring 'Gitlab under `| Attrs` therefore fails the contract outright —
`minimal dump` aborts with "failed to validate source_provenance" and the WHOLE
package set fails to evaluate, not just that package.

psmisc appears to contradict this: it ships `category = 'Gitlab` on main today.
It does not — psmisc's attrs block carries NO `| Attrs` annotation, so it is
never contract-checked. That is an accident, not a pattern to copy, and it means
we currently have one package whose provenance the contract has never seen.

So the pkgs half of the GitLab provenance work was never merely forgotten — it
was not expressible. Raising the stdlib gap is a minimal-side decision, so this
PR stops at the two packages that can land today rather than working around a
contract.
@coderabbitai

coderabbitai Bot commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: fb481041-cacf-42ee-a8da-0409f6af5582

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

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

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.

1 participant