News for hackers. Stuff that matters.

A comment on What NPM should do to stop a new colors attack. Parent comment

Re:What NPM should do to stop a new colors attack by hn_throwaway_99 on Monday January 10, 2022 @04:57PM (#29883285)
The "bad" colors.js existed for less than 24 hours before it was removed by NPM. Similarly the other recent malicious packages were detected and removed quickly.

The idea is that for maliciously published packages like this (both deliberately in this case, and also when the maintainer's account is hacked) that not all packages that depend on this dependency will need the same length of N. Some users will want to pick it up right away, but some very conservative applications may want N to be much longer. It's basically the idea that alpha/beta users can be the canaries, but those who don't want to take any risk can hold back. Right now, unless you've got a lock file, essentially everyone is pulling the latest released version whether they want to be conservative or not.

[ Parent | on HN ]
Re:What NPM should do to stop a new colors attack by umvi on Monday January 10, 2022 @05:15PM (#29883549)
Ah, that was the piece I was missing. Basically we are relying on NPM to curate/remove obvious bad packages from the global registry within some timeframe (say, 3 days) and by lagging behind by 3 days you'll never pick up an obvious bad package.
[ Parent | on HN ]