6 ms·

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

by ebfe1 1y ago

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

hiccuphippo 1y ago
The could force release candidates that the package managers don't automatically update to, but let researchers analyse the packages before the real release.
herpdyderp 1y ago
If I was forced to wait to download my own package updates I would simply stop using npm altogether and use something else.
- balder1991 1y ago
  It could be done like a rollout in % over time like app stores do.
- kaelwd 1y ago
  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 https://github.com/pnpm/pnpm/issues/9921
  - herpdyderp 1y ago
    Brilliantly simple, that would work for me!
  - ApolloFortyNine 1y ago
    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 1y ago
      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.
robjan 1y ago
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.
kaelwd 1y ago
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 1y ago
  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 https://news.ycombinator.com/item?id=43367987

by ebfe1 1y ago

hiccuphippo 1y ago

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

herpdyderp 1y ago

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

balder1991 1y ago
It could be done like a rollout in % over time like app stores do.
kaelwd 1y ago
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 https://github.com/pnpm/pnpm/issues/9921
- herpdyderp 1y ago
  Brilliantly simple, that would work for me!
- ApolloFortyNine 1y ago
  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 1y ago
    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.

robjan 1y ago

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.

kaelwd 1y ago

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 1y ago
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 https://news.ycombinator.com/item?id=43367987