Thank you for the thorough response. I got the following from yours and other responses:

* The JS ecosystem has been and will most likely continue to be fast-moving, so it's quite a safe assumption that at no point will a quarantine period be wide-spread.

* This quarantine period is for (semi-)automated scanners to catch the issue. Although considering the above there will always be a non-zero amount of end-user canaries as well.

* Maybe NPM should run scanners before distributing malware?

* If the ecosystem by any chance adopts a week-long quarantine period, you'd be safer if you applied a longer quarantine period.

▲

_flux an hour ago | parent [-]

> Maybe NPM should run scanners before distributing malware?

I suspect there's always a human checking these results. If NPM straight out rejects an update due to suspected malware, they might end up rejecting correct updates as well. If they grant some "safe" patterns a special pass, they might get exploited.

So I think this only works if you have security scanners that are well-maintained and kept in secret. NPM folks could of course co-operate with some security companies to have a first stab with the releases before they are put to public access. At some point some parties might start want to have monetary compensation for such an arragnement, though.

	▲	phoronixrly 31 minutes ago \| parent [-]
		Look, nobody requested fully automated scanners that are never wrong. A scanner that asks the project owner to sign in with 2fa and confirm the release in case it's been flagged is going to be more than sufficient.