[RRFC] Ability to set minimum maturity (in days) of versions to upgrade

limonte commented 1 year ago

Motivation ("The Why")

When a vulnerability is introduced to an npm package, it takes at least several days to discover the vulnerability and to report the vulnerable release to security databases (npm, Snyk, dependabot, etc.)

Because of that reason, it would make sense for developers who want stability and security for their projects to use 3rd party dependencies with version that matches these conditions:

as latest as possible (the obvious one)
free from vulnerabilities, i.e. not present in npm/Snyk/dependabot security databases
X days mature, because of the reason mentioned above - it takes time to discover and report vulnerabilities

There's existing --before parameter, but it doesn't work for this purpose

Examples

As a maintainer of a popular plugin I several times shipped a bug or a breaking change in a patch release. Usually, these issues are noticed by users during the next several hours and after several more hours, I ship another patch release with a fix.

And here's why --before wouldn't work:

some-cool-package has 6.6.6 with a bug released 4 days ago and 6.6.7 with bug-fix released 2 days ago
with --before="3 days" the buggy version would be installed which would be the exact opposite of desired
with --stabilityDays=3 neither 6.6.6 nor 6.6.7 would be installed which is desired because 6.6.6 is buggy and 6.6.7 is immature.

How

Current Behaviour

None.

Desired Behaviour

npm install --stabilityDays=3

References

Renovate has this feature, it's named stabilityDays: https://docs.renovatebot.com/configuration-options/#stabilitydays

Also stabilityDays is mentioned in this RFC: https://github.com/npm/rfcs/issues/549

ljharb commented 1 year ago

From #549:

waiting a length of time doesn’t increase security, and if such a practice became common then it would just delay discovery of vulnerabilities until after that time anyways

nlf commented 1 year ago

i'm a little confused how --before doesn't solve for this.. yes, you have to form the timestamp yourself but it won't install anything that's newer than the date listed, so if you give it a timestamp for 3 days ago that should be pretty close to what you're asking for. at install time we evaluate for and do our best to avoid known vulnerable versions of packages, however if there's no semver-compatible alternative then we don't have much choice but to go ahead and install it.

the second part of that problem will be addressed by audit policies which would be capable of refusing the installation of any package with a known vuln.

castarco commented 1 year ago

I introduced a new proposal that could accommodate a specific metadata field for this purpose (the goal of my proposal is entirely different, but certainly not incompatible).

In the #703 RFC I propose to introduce a new updatePolicy section to provide finer grained control over how we update our dependencies (direct and transitive). We could introduce there a field called minReleaseMaturity that accepted temporal interval values in format ISO 8601; then, if the package manager respects that field, it should never update to a dependency that is not "mature enough".

In any case, I agree with this remark from @ljharb: https://github.com/npm/rfcs/issues/646#issuecomment-1282497113

npm / rfcs