[ebfe1]

Is it just me who think this could have been prevented if npm admins put in some sort of cool off period to only allow new versions or packages to be downloaded after being published by "x" amount of hours? This way the npm maintainer would get notifications on their email and react immediately? And if it is urgent fix, perhaps there can be a process to allow npm admin to approve and bypass publication cool off period.

Disclaimer: I don't know enough of npm/nodejs community so I might be completely off the mark here

[herpdyderp]

If I was forced to wait to download my own package updates I would simply stop using npm altogether and use something else.

[kaelwd]

It would be fine if you could still manually specify those versions eg. npm i duckdb@1.3.3 installs 1.3.3 but duckdb@latest or duckdb@^1.3 stays on 1.3.2 until 1.3.3 is ~a week old.

https://github.com/pnpm/pnpm/issues/9921

[balder1991]

It could be done like a rollout in % over time like app stores do.

[kaelwd]

NPM could also flag releases that don't have a corresponding github tag (for packages that are hosted on github), most of these attacks are publishing directly to NPM without any git changes.

[mdaniel]

I would love this for every dependency manager, and double extra bonus for "the tag NOW isn't the tag from when the dep was published"

But, this coming from GitHub, who believe that sliding "v1" tags on random action repos is how one ends up with https://news.ycombinator.com/item?id=43367987

[robjan]

They could definitely add a maker-checker process (similar to code review) for new versions and make it a requirement for public projects with x number of downloads per week.

[hiccuphippo]

The could force release candidates that the package managers don't automatically update to, but let researchers analyse the packages before the real release.