It could require a 48 hour cooldown period on any package update that wants to add an install script that didn't have one before, and has a certain number of downloads. And it could publish the list of these so security researchers have an opportunity to scan them.
It could add an optional key to package.json that allows someone to whitelist which packages can run install scripts.
It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI; (2) this hardened package status would be public, and (3) a developer could set a flag in their package.json that causes any npm action to act as if all non-hardened packages had frozen versions.
And so much more.
> It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI;
Great, they did this.
> And so much more.
This shit takes time. Yes, they should have done this on day 1. Acting like any of this is easy to retrofit is just nuts though.
Of course this should have been started since the beginning of the major recent stream of supply chain attacks, circa 2024 or 2025... but even assuming the most backwards calendaring possible -starting after the last bug compromise (Axios, on March 31st)- that new flag should have already been shipped a couple weeks ago.
Shit does take time, but where there's a will there's a way, and nobody buys that this shit would take that much time.
It's also the standard, and by far it's the contrast to not allow this. pnpm has a massive advantage of being the non-standard package manager, npm does not have that - what do you suggest that npm does?