OSV v3 parser shares introduced/fixed commit patches across affected packages

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#2,489 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@Celestial-0 arbeitet bereits daran.

Seit 03.11.2026.

  • #2490 von @Celestial-0 — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
84/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
backend

Rechercherichtung

Beginne in vulnerabilities/pipes/osv_v2.py bei parse_advisory_data_v3, wo der Issue auf die Commit-Listen hinweist, die initialisiert und an jedes Paket übergeben werden. Führe die Regressionstests des echten Parsers für unterschiedliche Git-Blöcke und einen Block, der nur Versionen enthält, in beliebiger Reihenfolge aus; fertig ist es, wenn jedes Paket nur seine eigenen Commits und separate Listen erhält, während sich mehrere Git-Bereiche innerhalb eines Blocks weiterhin ansammeln.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

When an OSV advisory contains multiple affected blocks, parse_advisory_data_v3 puts all collected Git commits into each parsed package. Packages with only version ranges inherit commits too.

Reproduced on current main, commit 8af2bd39510f909c852c5cc086e9b56addc8c50a, with Python 3.12.14, univers==32.0.1, and packageurl-python==0.17.6.

Reproduction

Run this in the project's configured Django shell. The package names, repositories and hashes below are synthetic. Parsing these GitHub URLs does not fetch any repositories.

python manage.py shell

from vulnerabilities.pipes.osv_v2 import parse_advisory_data_v3

raw = {
    "id": "x_REPRO-OSV-COMMIT-SCOPE",
    "modified": "2026-11-03T00:00:00Z",
    "affected": [
        {
            "package": {"ecosystem": "PyPI", "name": f"demo-{suffix}"},
            "ranges": [{
                "type": "GIT",
                "repo": f"https://github.com/example/repo-{suffix}",
                "events": [{"introduced": intro * 40}, {"fixed": fixed * 40}],
            }],
        }
        for suffix, intro, fixed in [("a", "a", "b"), ("b", "c", "d")]
    ],
}
advisory = parse_advisory_data_v3(
    raw, ["pypi"], "https://example.org/advisory", ""
)
first, second = advisory.affected_packages
for package in advisory.affected_packages:
    print(package.package, len(package.introduced_by_commit_patches),
          len(package.fixed_by_commit_patches))
print(first.introduced_by_commit_patches is second.introduced_by_commit_patches)
print(first.fixed_by_commit_patches is second.fixed_by_commit_patches)

Actual output:

pkg:pypi/demo-a 2 2
pkg:pypi/demo-b 2 2
True
True

Each package contains both repositories' introduced and fixed commits. Expected output is 1 1 for each package and separate lists: demo-a should only have repo-a commits and demo-b only repo-b commits.

With a Git block and a version-only block in the same advisory, the version-only package receives the Git block's introduced and fixed patches in either order.

Cause

The parser initializes the two commit lists before the affected-package loop and passes them unchanged to every AffectedPackageV2. The constructor validates the lists without copying them, so the parsed advisory associates packages with other packages' commits.

The lists should be initialized for each affected block, alongside its version constraints. Multiple Git ranges within the same block should still accumulate into that block's lists.

I checked existing OSV issues and PRs, including #2080, #2066, #2116 and the current parser PRs, and found no report of this attribution bug. Tests using the real parser and classifier fail for two distinct Git blocks and for a version-only block in either order. The control with multiple Git ranges in one block passes.

I'd like to work on the fix. Would you welcome a PR that scopes the lists to each affected block and adds these regression tests?

Vorherrschende Sprache
Python
Sterne
717
Forks
352
Ø Merge
6 Std. 19 Min.
Gemergte PRs (30 T.)
6

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus aboutcode-org/vulnerablecode

Alle Issues in aboutcode-org/vulnerablecode

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.