Minimum release age and security fixes

[wereHamster]

I think we can generally agree that minimum release age is a good setting to use to avoid running into certain types of vulnerabilities. However it's a bit at conflict with security fixes that need to be applied ASAP.

I noticed that Renovate and Dependabot fail to create security PRs due to the minimumReleaseAge setting, they have not yet learned how to work with (or around) it.

I know minimumReleaseAgeExclude exists, however it's not very ergonomic. Consider the following example: I want to allow [email protected] so I add it to minimumReleaseAgeExclude. However next depends on @next/env so I need to add that too. So I not only need to add my own dependencies, but also all the transitive dependencies of the vulnerable package that I want to bump.

I further noticed that npm audit --fix will add overrides, but in a way that makes pnpm install still pick a vulnerable version.

overrides:
  next@>=15.5.0-canary.0 <15.5.7: '>=15.5.7'

Because version 15.5.7 is within the minimum age window, pnpm installs 16.0.5 (which is also vulnerable). And if I set the override to exact version 15.5.7, pnpm refuses due to the minimum age window.

The only way I see how to apply the security fix is to temporarily remove the minimumReleaseAge setting from my workspace, bump that one package, and then reinstate the setting. That however has still a downside that during any future package installation, pnpm will remove optional dependencies that are inside the minimum release age window (#10270).

I don't see a way to make security fixes work in the presence of minimumReleaseAge. If there is a way, I'd appreciate guidance. But perhaps the two are, in the current form of pnpm, incompatible, and need a new setting or changes in pnpm behavior.

Ideally, there would be a way to specify that a specific (minimum) version of a package is required, ignoring any other settings that would interfere with its installation (including transitive dependencies). I'd also prefer the change to update only to the least compatible version (the one that fixes the vulnerability), not like >=15.5.7 in my earlier example which can bump the dependency across major versions.

[zkochan]

I was thinking about adding something like minimumReleaseAgeLoose. When true, pnpm will first try to resolve the range from mature versions. If that fails, it will pick a version that satisfies the range, ignoring the maturity requirement.

I'd also prefer the change to update only to the least compatible version (the one that fixes the vulnerability), not like >=15.5.7 in my earlier example which can bump the dependency across major versions.

I believe we take this range from npm's audit report. I don't have objections to use a proper range with ^ if we can calculate it.

[wereHamster]

If that fails, it will pick a version that satisfies the range, ignoring the maturity requirement.

…but only for dependencies that are needed to satisfy overrides. I wouldn't want this setting to relax the maturity requirement for other dependencies.

I'd prefer using overrides (or a mechanism like overrides) where I can set minimum requirements for dependencies (optionally tie to specific CVEs), that would ignore any maturity requirements.

I see overrides are being used for two different things. One is for non-security purposes, to fix bugs in transitive dependencies or to keep a consistent version of some package in the workspace. The other is security purposes (manually specified overrides or generated by pnpm audit --fix). The former should respect minimumReleaseAge while the later should overrule that setting.