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 5 days ago | parent | next [-]

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

▲

kaelwd 5 days ago | parent | next [-]

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

▲

ApolloFortyNine 5 days ago | parent | next [-]

Except they'd have to have an override for when there's a zero day, at which point we're back where we started.

	▲	kaelwd 5 days ago \| parent [-]
		Versions with a serious vulnerability should be deprecated by the maintainer which then warns you to use a newer version when installing. Yes if a npm account is compromised the attacker could deprecate everything except their malicious version but it would still significantly reduce the attack surface by requiring manual intervention vs the current npm install foo@latest -> you're fucked.

▲

herpdyderp 5 days ago | parent | prev [-]

Brilliantly simple, that would work for me!

▲

balder1991 5 days ago | parent | prev [-]

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

▲

kaelwd 5 days ago | parent | prev | next [-]

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 4 days ago \| parent [-]
		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 5 days ago | parent | prev | next [-]

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 5 days ago | parent | prev [-]

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