Regression in getting Apache Hadoop vulnerabilities by commit hash

[sschuberth]

Describe the bug

A functional test for Google OSV integration in ORT started to fail a few days ago due to the OSV API not returning the expected vulnerability (CVE-2022-26612) for commit a3b9c37a397ad4188041dd80621bdeefc46885f2 (tag 3.3.1) anymore.

To Reproduce

Steps to reproduce the behaviour:

1. curl -d '{"commit": "a3b9c37a397ad4188041dd80621bdeefc46885f2"}' "https://api.osv.dev/v1/query"

Expected behaviour

A non-empty JSON response.

Screenshots

n/a

Additional context

Previously returned data in ORT-specific YAML serialization:

- id: "CVE-2022-26612"
  description: "In Apache Hadoop, The unTar function uses unTarUsingJava function\
    \ on Windows and the built-in tar utility on Unix and other OSes. As a result,\
    \ a TAR entry may create a symlink under the expected extraction directory which\
    \ points to an external directory. A subsequent TAR entry may extract an arbitrary\
    \ file into the external directory using the symlink name. This however would\
    \ be caught by the same targetDirPath check on Unix because of the getCanonicalPath\
    \ call. However on Windows, getCanonicalPath doesn't resolve symbolic links, which\
    \ bypasses the check. unpackEntries during TAR extraction follows symbolic links\
    \ which allows writing outside expected base directory on Windows. This was addressed\
    \ in Apache Hadoop 3.2.3"
  references:
  - url: "https://security.netapp.com/advisory/ntap-20220519-0004/"
    scoring_system: "CVSS_V3"
    severity: null
    score: null
    vector: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
  - url: "https://lists.apache.org/thread/hslo7wzw2449gv1jyjk8g6ttd7935fyz"
    scoring_system: "CVSS_V3"
    severity: null
    score: null
    vector: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"

[jess-lowe]

From a cursory look at the new record, it seems like the tag is not being successfully fuzzy matched. Will investigate further. Thanks for the report.