hacked package mitigation - minimum package age

[rafipiccolo]

• I have searched for similar issues
• I am using the latest version of npm-check-updates
• I am using node >= 10.17

---

** problem **
latest version of packages may sometimes be buggous / hacked.
Usually the hacked version are blocked some hours after. same goes for bugs. A new/safer version is released some hours/days after.
Here is an exemple of hack, a few days ago : https://portswigger.net/daily-swig/popular-npm-package-ua-parser-js-poisoned-with-cryptomining-password-stealing-malware
the hacked packages were deleted in ~5hours.

** solution **
to handle bugs, everyone need to test his own codebase with unit tests. (i'm trying to do this)
To handle hacks, i would like a way to install latest package version but ignoring packages that are less than 1 day old.
maybe a new option on the cli, like --min-age NUMBER_OF_DAYS to ignore package version that are too young.

Maybe you have a better solution ? Or is it too hard to implement ?

[raineorshine]

Thanks for the suggestion! This is technically doable, since the publish time of each version is available in the npm registry, e.g. npm view chalk time. It could be like the newest function but first filtered by min-age.

The --min-age option would make sense with --target newest, but it's not so clear how it should behave with the default --target latest. What happens if the latest version does not meet the min-age criteria? There is no history of versions published to the latest tag, and the next sequential version or previously published version may be a pre-release. You would need a target like newest or greatest that has a sequential list of versions it can fall back to. Or it could omit the dependency completely, which is not a bad idea, since it will pick it up again once the min-age has passed.

[rafipiccolo]

| Or it could omit the dependency completely, which is not a bad idea, since it will pick it up again once the min-age has passed
=> i like it. min-age comes first.

to clarify my use case i would say that i was confidently doing this until this recent hack :

ncu --target minor

that way i get all minor versions updated, then i run checks

npm install
npm test

and if all is good i deploy to production.
i dont want to install a minor too early since bugs / hacks are in there.

i also call npm directly to detect if a major version is available to migrate the code and deploy manually.

a valid algorithm - for me - would be to

• select all versions for a particular package from npm
• filter to remove too young packages if --min-age is specified
• apply target rules

[raineorshine]

a valid algorithm - for me - would be to

select all versions for a particular package from npm
filter to remove too young packages if --min-age is specified
apply target rules

Do you wish to include betas, and pre-releases, or only stable versions? As mentioned above there is no way that I know of to get a history of versions published to the latest tag. But we can get a list of all published versions.

to clarify my use case i would say that i was confidently doing this until this recent hack :

ncu --target minor
that way i get all minor versions updated, then i run checks

npm install
npm test

Try out ncu -u --doctor --target minor. It will install all minor upgrades, run your tests, identify any breaking upgrades, and give you the maximum non-breaking upgrades.

[raineorshine]

Duplicate of #833

[rafipiccolo]

Do you wish to include betas, and pre-releases, or only stable versions?

I dont really care as long as the package is old enough to be considered for update and my mocha passes.
tbh i didnt notice what exatly target minor / major or semver in general does regarding betas but i dont think --min-age should alter that.

[raineorshine]

Still an open issue, but closing in favor of #833.