News for hackers. Stuff that matters.

A comment on DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware.

Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by ebfe1 on Tuesday September 09, 2025 @07:54AM (#45180683)
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

[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by herpdyderp on Tuesday September 09, 2025 @08:41AM (#45181162)
If I was forced to wait to download my own package updates I would simply stop using npm altogether and use something else.
[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by kaelwd on Tuesday September 09, 2025 @10:03AM (#45182087)
It would be fine if you could still manually specify those versions eg. npm i [email protected] 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

[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by ApolloFortyNine on Tuesday September 09, 2025 @10:51AM (#45182729)
Except they'd have to have an override for when there's a zero day, at which point we're back where we started.
[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by kaelwd on Tuesday September 09, 2025 @11:10AM (#45183021)
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.
[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by herpdyderp on Tuesday September 09, 2025 @10:35AM (#45182522)
Brilliantly simple, that would work for me!
[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by balder1991 on Tuesday September 09, 2025 @08:50AM (#45181253)
It could be done like a rollout in % over time like app stores do.
[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by hiccuphippo on Tuesday September 09, 2025 @09:01AM (#45181371)
The could force release candidates that the package managers don't automatically update to, but let researchers analyse the packages before the real release.
[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by robjan on Tuesday September 09, 2025 @09:12AM (#45181498)
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.
[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by kaelwd on Tuesday September 09, 2025 @11:15AM (#45183092)
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.
[ Parent | on HN ]
Re:DuckDB NPM packages 1.3.3 and 1.29.2 compromised with mal... by mdaniel on Tuesday September 09, 2025 @10:08PM (#45192236)
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

[ Parent | on HN ]