Re:What NPM should do to stop a new colors attack
by umvi on Monday January 10, 2022 @04:42PM
(#29883046)
How do you tell your "baked" version is any good though? Doesn't that mean N days after colors.js ground zero you'll start picking up the bad colors.js since it's now baked for N days?
[ Parent
| on HN ]
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.
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.