Skip to content

chore(deps): bump vuls2 and vuls-data-update for openssh RangeType - #2643

Closed
MaineK00n wants to merge 1 commit into
masterfrom
MaineK00n/bump-vuls2-openssh
Closed

chore(deps): bump vuls2 and vuls-data-update for openssh RangeType#2643
MaineK00n wants to merge 1 commit into
masterfrom
MaineK00n/bump-vuls2-openssh

Conversation

@MaineK00n

Copy link
Copy Markdown
Collaborator

Fixes #2642

What

Bumps the vuls2 / vuls-data-update pins so the enum vocabulary matches the vuls-data-update nightly branch again:

  • github.com/MaineK00n/vuls2 7a8b91a51f44ab3a3111c7f1
  • github.com/MaineK00n/vuls-data-update 305a95f8ba564b1dbcf513ff

The drift the scheduled check-enums run reported was a single new value:

> pkg/extract/types/data/detection/condition/criteria/criterion/cpecriterion/range.RangeType	openssh

Bumped upstream first, per the playbook in the issue: MaineK00n/vuls2#425 already pins vuls-data-update 4b1dbcf, so pinning that vuls2 nightly merge commit here raises the direct vuls-data-update requirement to the same version through module graph resolution. That keeps this repo, the standalone vuls2 binary, and the vulsio/vuls-data-db nightly build on one vocabulary — bumping vuls-data-update here alone would leave the binary that builds the DB skipping data carrying the new range type.

Incoming

vuls2 (7a8b91a51f44...ab3a3111c7f1):

vuls-data-update (305a95f8ba56...4b1dbcf513ff):

Verification

  • GOEXPERIMENT=jsonv2 go run github.com/MaineK00n/vuls-data-update/tools/print-enums for the new pin vs ...@4b1dbcf513ff1522de398d087c29e44a9c5a38bf — diff is empty (143 lines each).
  • go build ./... and go test ./... pass (with the integration submodule checked out).

Converting the new source's detection results into vuls0 report models (CveContentType, confidences, advisory links) is separate follow-up work; this PR only realigns the pins so the values stop being dropped.

The pinned vuls-data-update knew fewer enum values than the nightly
branch: cpecriterion/range.RangeType gained `openssh`, so detection
would skip criteria carrying it once the nightly DB starts emitting
them.

Bumped upstream first, as the drift playbook requires — MaineK00n/vuls2#425
pins vuls-data-update 4b1dbcf, so pinning that vuls2 merge commit here
raises the direct vuls-data-update requirement to the same version and
keeps the standalone vuls2 binary and the vuls-data-db nightly build on
one vocabulary.

Incoming:

- MaineK00n/vuls2#425 chore(deps): bump vuls-data-update for openssh security
- MaineK00n/vuls-data-update#928 feat(openssh/security): add OpenSSH security advisory data source
- MaineK00n/vuls-data-update#939 fix(extract/apple): bound 10.x in-line updates below by their own line

`print-enums` for the new pin against 4b1dbcf diffs empty.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@MaineK00n MaineK00n self-assigned this Aug 19, 2026
@MaineK00n

Copy link
Copy Markdown
Collaborator Author

Superseded by #2636, which landed the same pins (vuls2 ab3a3111c7f1 / vuls-data-update 4b1dbcf513ff) as part of the OpenSSH detector work. Rebasing this branch onto master dropped the commit — "patch contents already upstream" — so there is nothing left to merge. Closing; #2642 is resolved by #2636.

@MaineK00n MaineK00n closed this Aug 19, 2026
@MaineK00n
MaineK00n deleted the MaineK00n/bump-vuls2-openssh branch August 19, 2026 05:43
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.

vuls-data-update enum vocabulary drift

1 participant