OSV disables upgrading to patched version

[astellingwerf]

What would you like help with?

I think I found a bug

How are you running Renovate?

Self-hosted

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

37.377.7

Please tell us more about your question or problem

Python's requests version 2.31.0 is susceptible to a new CVE. OSV knows about it, see https://osv.dev/vulnerability/CVE-2024-35195. Versions 2.32.0 and later contain the fix for this, but that exact version has been yanked, see https://pypi.org/project/requests/#history.

Despite (no, actually because) we've enabled osvVulnerabilityAlerts, Renovate provides no option to update to a new version with the fix. Vulnerabilities.getFixedVersion puts a final == on the yanked fix version in allowedVersions, meaning that I can't automatically update to a version with the fix, such as 2.32.2.

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[viceice]

the osv entry should be updated to a version which isn't yanked

[astellingwerf]

I reported google/osv.dev#2251 and github/advisory-database#4468 accordingly.

But, we could work around the issue by changing the == to >=. Do we know why it's a hard equals instead of "this version or newer"?

[rarkins]

Renovate's other vulnerability handling (GitHub alerts, or Mend's SCA products) use >= for this reason plus this logic:

renovate/lib/workers/repository/process/lookup/index.ts

Lines 364 to 366 in 9e2ca6b

	if (config.isVulnerabilityAlert && !config.osvVulnerabilityAlerts) {
	filteredReleases = filteredReleases.slice(0, 1);
	}

In other words it becomes "take the first release which exists greater than or equal to x.y.z". Usually it's x.y.z but sometimes it can be higher due to reasons like this.

I wasn't involved in the OSV implementation although you can see from the code I linked to that @Churro was aware of it when implementing

[Churro]

I don't remember why back then I thought it's necessary to treat OSV alerts differently but I can verify this over the next few days.

---

Edit by @HonkingGoose: here's the issue to track that work. 😉

• Verify OSV alert logic (and maybe make code changes as needed) #29342

[github-actions[bot]]

Hi there,

Get your discussion fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.

Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. Discussions without reproductions are less likely to be converted to Issues.

To get started, please read our guide on creating a minimal reproduction.

Good luck,

The Renovate team

[astellingwerf]

https://github.com/astellingwerf/renovate-requests-allowedVersion

[HonkingGoose]

The reproduction looks minimal to me, so I've forked it into our reproductions organization here:

• Our fork of your reproduction for Discussion 29280 and Issue 29342

@astellingwerf can you please add a readme.md file to your reproduction repository that explains the ## Current behavior and the ## Expected behavior? I'll then pull in the readme on the fork. 😉

See our creating a minimal reproduction guide for more info.

[rarkins]

When I run against it, all I see is a working PR: renovate-reproductions/29280-and-29342#1

I think a simpler reproduction would have been a requirements.txt with one line

[astellingwerf]

That might be true, but it's further from my actual scenario. That's why I decided to do it like this.

I thought I had reduced the repro even further but now I don't run into it anymore, please allow me to figure out why that is...

[Churro]

tl;dr: the OSV package rule requests "allowedVersions": "==2.32.0" but renovate already filters "2.32.0" due to its status as deprecated. This results in an empty list of filtered releases and hence no PR.

Explanation:

• The pypi datasource returns the following for requests:

...
{ "version": "2.31.0", "releaseTimestamp": "2023-05-22T15:12:42.000Z" },
{ "version": "2.32.0", "isDeprecated": true, "releaseTimestamp": "2024-05-20T16:08:19.000Z" },
{ "version": "2.32.1", "isDeprecated": true, "releaseTimestamp": "2024-05-20T22:08:45.000Z" },
{ "version": "2.32.2", "releaseTimestamp": "2024-05-21T18:51:29.000Z" },
...

• renovate's OSV integration (and the Github vuln alert integration as well, btw) defines a package rule that looks like this:

{
  "matchDatasources": ["pypi"],
  "matchPackageNames": ["requests"],
  "matchCurrentVersion": "2.31.0",
  "allowedVersions": "==2.32.0",
  "isVulnerabilityAlert": true,
  ...
}

• While looking up versions, filterVersions skips deprecated (yanked) versions due to the ignoreDeprecated: true setting (ref):
  

  renovate/lib/workers/repository/process/lookup/filter.ts

  Lines 48 to 52 in 9e2ca6b

  	if (ignoreDeprecated && fromRelease && !fromRelease.isDeprecated) {
  	filteredVersions = filteredVersions.filter((v) => {
  	const versionRelease = releases.find(
  	(release) => release.version === v.version,
  	);

  
  which is also visible in logs as:

TRACE: Skipping requests@2.32.0 because it is deprecated (repository=requestsdemo)
TRACE: Skipping requests@2.32.1 because it is deprecated (repository=requestsdemo)

• Hence, filteredReleases is empty even before this check is executed:
  

  renovate/lib/workers/repository/process/lookup/index.ts

  Lines 364 to 366 in 9e2ca6b

  	if (config.isVulnerabilityAlert && !config.osvVulnerabilityAlerts) {
  	filteredReleases = filteredReleases.slice(0, 1);
  	}

  
  So summarizing, due to renovate filtering deprecated releases early on, it skips 2.32.0. With ignoreDeprecated: false, it would create a PR for 2.32.0 -> Update dependency requests to v2.32.0 [SECURITY] renovate-demo/29280#1

• For this clause to be triggered, the package rule would need to contain "allowedVersions": ">=2.32.0", which is neither the case for Github, nor OSV alerts. Assuming this would be the case, here is where Github and OSV vuln alerts are currently handled differently:

  • for GHSA, the next non-vulnerable version would be chosen,
  • for OSV >= means the most recent is proposed. I tend to think this special condition for OSV should be dropped but I'd first cross-check this on my OSV demo repos, e.g., https://github.com/renovate-demo/6562-vulndemo for some additional confidence.

Probably, it would make sense to never require an exact version for GHSA and OSV alerts but always use >= instead of == (or the respective syntax for Maven) and then pick the lower bound release (as already done for GHSA). If I understood #29280 (reply in thread) correctly, this is the expected case anyway.

[HonkingGoose]

Does this comment mean that OSV alerts are working as expected and that we can keep the Renovate code as-is?

Also, does this mean I can close the related issue as done?

[Churro]

I'm thinking about making a PR with the changes that were suggested but didn't find the time to focus on this yet.

[Churro]

Fix -> #29666