Skip to content

util/resolve: sort versions in matchRequirement - #386

Closed
miraeti wants to merge 1 commit into
google:mainfrom
miraeti:fix/385-match-requirement-sort
Closed

util/resolve: sort versions in matchRequirement#386
miraeti wants to merge 1 commit into
google:mainfrom
miraeti:fix/385-match-requirement-sort

Conversation

@miraeti

@miraeti miraeti commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

Fixes #385

Problem

The v3alpha API returns package versions sorted lexicographically by version string (e.g. for setuptools, "9.1.0" sorts after "84.0.0"). The default branch of MatchRequirement (used by PyPI and other non-NPM systems) passed the list through unsorted, but resolvers assume matches come back in ascending order, the PyPI resolver iterates candidates in reverse (attemptToPinCriterion) and pins the first one that works. Unpinned transitive requirements therefore resolve to the lexicographic maximum (e.g. setuptools 9.1.0 instead of 84.0.0), producing false-positive vulnerability reports in osv-scanner with --data-source deps.dev.

Fix

Call SortVersions at the top of matchRequirement, mirroring what the NPM branch already does with sortNPMVersions (util/resolve/match.go:163). Covers all systems on the default branch, not just PyPI.

Test

Adds TestMatchRequirement: feeds the lexicographic order returned by the API and asserts matches come back in ascending semver order; verified the test fails without the fix.

@cuixq

cuixq commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

Thanks for digging into this and identifying the root cause of the issue!

I am a bit concerned about sorting in matchRequirement: it should ideally be a pure filtering function - its only responsibility is to evaluate constraints against candidate versions and filtering matches. In addition, having the sorting in matchRequirement may introduce redundant sorting overhead considering it will be called many time during dependency resolution.

The root discrepancy is actually at the API client:

  • LocalClient already sorts versions in ascending semver order via SortVersions when they are added.
  • osv-scalibr's native PyPIRegistryClient.Versions also explicitly sorts versions with semver.PyPI.Compare before returning.
  • APIClient.Versions() was the only place that returns raw lexicographical order from the backend API.

Therefore, what do you think about:

  1. Sorting in APIClient.Versions() util/resolve/api.go?
  2. Documenting on Client.Versions in util/resolve/client.go to make it clear that the versions should be sorted?

@miraeti
miraeti force-pushed the fix/385-match-requirement-sort branch from 69f0d5c to 70e045f Compare August 26, 2026 16:52
@miraeti miraeti closed this Aug 26, 2026
@miraeti
miraeti deleted the fix/385-match-requirement-sort branch August 26, 2026 16:52
@miraeti

miraeti commented Aug 26, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for the review @cuixq

Good point about keeping matchRequirement a pure filter. I've reworked the fix per your suggestion. The sort now happens in APIClient.Versions, and the ordering contract is documented on Client.Versions.

Heads up: this PR was automatically closed when I renamed the head branch. The reworked change is now in #387 .

cuixq pushed a commit that referenced this pull request Aug 27, 2026
Fixes #385.

Supersedes #386 (closed after a head-branch rename)

Continuing the review thread with @cuixq, who suggested sorting at the
API client layer and documenting on `Client.Versions` that the versions
should be sorted.

## Problem

`APIClient.Versions` returned versions in the order returned by the
deps.dev API, which is not ascending (for PyPI, at least, it is
lexicographic, where "9.1.0" comes after "84.0.0"). The PyPI resolver
iterates the version list in descending order, relying on it being
sorted ascending, so unpinned transitive requirements resolved to the
lexicographic maximum (e.g. `setuptools 9.1.0` instead of `84.0.0`).

## Fix

Sort the versions in `APIClient.Versions`, the layer that converts the
API response, and document the ordering contract on `Client.Versions`.

## Test

`TestVersions` feeds a lexicographically ordered PyPI version list to
`APIClient.Versions` and asserts the ascending order, and verified the
test fails without the fix.
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.

PyPI resolver pins lexicographically-greatest version (e.g. setuptools 9.1.0) instead of highest semver when using the deps.dev API as data source

2 participants