Hacker News Reader

Comment by bakugo | Hacker News Reader

> According to the npm statistics, nobody has downloaded these packages before they were deprecated

Is this actually accurate? Packages with weekly downloads in the hundreds of thousands, yet in the 4+ hours that the malicious versions were up for, not a single person updated any of them to the latest patch release?

View on HN

DuckDB maintainer here, thanks for flagging this. Indeed the npm stats are delayed. We will know in a day or so what the actual count was. In the meantime, I've removed that statement.

I think you should unpublish rather than deprecate... `npm unpublish package@version` ... It's possible within 72h. One reason is that the patched version contains -alpha... so tools like npm-check-updates would keep the 1.3.3 as the latest release for those who installed it

Yes we tried, but npm would not let us because of "dependencies". We've reached out to them and are waiting for a response. In the meantime, we re-published the packages with newer versions so people won't accidentally install the compromised version.

At least one thing is clear from this week: npm is too slow to respond.

> npm is too slow to respond

Microsoft has been bravely saying "Security is top priority" since 2002 (https://www.cnet.com/tech/tech-industry/gates-security-is-to...) and every now and then reminds us that they put "security above all else" (latest in 2024: https://blogs.microsoft.com/blog/2024/05/03/prioritizing-sec...), yet things like this persists.

For how long time do Microsoft need to leave wide-open holes for the government to crack down on their wilful ignorance? Unless people go to jail, literally nothing will happen.

TIL that NPM is a subsidiary of GitHub, making this indeed Microsoft's responsibility.

they have now removed the affected versions!

Disclosure: I’m the founder of https://socket.dev

npm stats lag. We observed installs while the malicious versions were live for hours before removal. Affected releases we saw: duckdb@1.3.3, @duckdb/duckdb-wasm@1.29.2, @duckdb/node-api@1.3.3, @duckdb/node-bindings@1.3.3. Same payload as yesterday’s Qix compromise. Recommend pinning and avoiding those versions, reviewing diffs, and considering a temporary policy not to auto-adopt fresh patch releases on critical packages until they age.

I think that's pretty unlikely. I aren't even a high-profile npm author, and if I publish any npm package they end up being accessed/downloadaded within minutes of first publish, and any update after that.

I also know projects who are reading the update feeds and kick off CI jobs after any dependencies are updated to automatically test version upgrades, surely at least one dependent of DuckDB is doing something similar.

Reply on news.ycombinator.com