Skip to content

feat(detector/vuls2): adopt forward-compatible enum serde and surface evaluation warnings#2609

Draft
shino wants to merge 7 commits into
masterfrom
shino/vuls2-enum-warnings
Draft

feat(detector/vuls2): adopt forward-compatible enum serde and surface evaluation warnings#2609
shino wants to merge 7 commits into
masterfrom
shino/vuls2-enum-warnings

Conversation

@shino

@shino shino commented Jul 23, 2026

Copy link
Copy Markdown
Collaborator

What

Adopt the forward-compatible enum serde line from vuls-data-update / vuls2, and surface vuls2's evaluation warnings in scan results:

  • chore(deps): bump vuls-data-update to the nightly containing feat!(extract/types): convert enum types to string MaineK00n/vuls-data-update#887 (string enums, lenient serde, FilteredCriterion.Warnings), and vuls2 to the head of feat(detect): adopt forward-compatible enum serde from vuls-data-update MaineK00n/vuls2#412.
  • feat(detector/vuls2): data this binary cannot evaluate (e.g. enum values produced by a newer vuls-data-update) is skipped during detection with a warning recorded on the FilteredCriteria trees. detect() aggregates them via vuls2/pkg/detect.CollectWarnings (grouped map[SourceID]map[Kind][]cause) — before any affected gating prunes the not-affected conditions carrying them — and detectWith() projects one warning line per (source, kind) with its causes into ScanResult.Warnings (sorted iteration for determinism, deduplicated across the pkgs / cpe passes), so a silent skip is distinguishable from a genuine not-affected.
  • ci: a check-enums workflow (daily cron + workflow_dispatch — deliberately not per-PR: it checks a repository-wide condition no PR author controls, and per-PR runs would fail unrelated/dependabot PRs on upstream drift and block maintenance-line hotfixes) diffs the enum known sets of the go.mod-pinned vuls-data-update against its nightly branch via tools/print-enums. Any diff means a dependency bump is due before data produced with the new values reaches detection. A scheduled failure files one deduplicated enum-drift issue assigned to the maintainers, carrying the enum diff and the run link.

Why draft

The vuls2 pin is tentative: it points at the head of MaineK00n/vuls2#412 (dbdb3cd). Once that PR merges to vuls2 nightly, re-pin go.mod / go.sum to the merged commit and mark this ready.

Testing

  • GOEXPERIMENT=jsonv2 go test ./... green against the pinned modules.
  • The CI diff command was run locally from this module: diff clean.

🤖 Generated with Claude Code

shino and others added 7 commits July 23, 2026 18:49
…num serde

vuls-data-update is pinned to the nightly containing
MaineK00n/vuls-data-update#887 (string enums with lenient serde and the
FilteredCriterion.Warnings machinery). vuls2 is TENTATIVELY pinned to
the head of MaineK00n/vuls2#412 (the consumer-side adaptation); re-pin
to the nightly commit once that PR merges.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Data a vuls binary cannot evaluate (e.g. enum values produced by a newer
vuls-data-update) is skipped during vuls2 detection with a warning
recorded on the FilteredCriteria trees. Aggregate them via
vuls2/pkg/detect.CollectWarnings before any affected gating prunes the
not-affected conditions carrying them, and project them into
ScanResult.Warnings (deduplicated across the pkgs / cpe passes) so a
silent skip is distinguishable from a genuine not-affected.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Fail when the vuls-data-update pinned in go.mod knows fewer enum values
than its nightly branch — a dependency bump is due before data produced
with the new values reaches detection. The known sets are append-only,
so a plain diff of tools/print-enums output suffices. Runs on every PR
and on a daily schedule.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The check tests a repository-wide condition — whether the pinned
vuls-data-update lags nightly — not anything a PR author controls.
Per-PR runs would fail unrelated work (including dependabot bumps of
other modules) whenever upstream drifts, and would permanently block
hotfix PRs on maintenance lines whose pins are legitimately old. The
daily cron is the drift alarm; workflow_dispatch covers on-demand
checks while preparing a bump PR.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Drift is a state, not an event — it persists until a bump PR merges —
so the alarm is one open issue (deduplicated by the enum-drift label,
assigned to the vuls2-integration maintainers, carrying the enum diff
and the run link) instead of a notification that depends on whoever
last edited the cron.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vuls2's DetectResult.Warnings is now map[SourceID]map[Kind][]cause;
render one scan-result warning line per (source, kind) with the causes
listed, iterating in sorted order for deterministic output. Empty-string
causes (unset datum, or the constant collected by cause-less kinds like
empty-range) stay in the data but are not rendered. The vuls2 pin moves
to the head of MaineK00n/vuls2#412 accordingly (still tentative until
that PR merges).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The diff job runs go run on code fetched from the upstream nightly
branch; keeping issues: write on that same job would hand a compromised
upstream the ability to write issues here. Split the issue filing into
its own job (no checkout, no upstream code, issues: write only) fed via
job outputs, and resolve the moving branch to a commit once per run so
execution, the log, and the filed issue all refer to the same revision.

Co-Authored-By: Claude Fable 5 <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.

1 participant