5 ms·

> According to the npm statistics, nobody has downloaded these packages before they were deprecated Is this actually accurate? Packages with weekly downloads i

by bakugo 1y ago

> 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?

diggan 1y ago
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.
hfmuehleisen 1y ago
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.
- belgattitude 1y ago
  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
  - hfmuehleisen 1y ago
    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.
    - hfmuehleisen 1y ago
      they have now removed the affected versions!
    - herpdyderp 1y ago
      At least one thing is clear from this week: npm is too slow to respond.
      - diggan 1y ago
        > 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-top-priority/ 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-security-above-all-else/ 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.
        zahlman 1y ago
        TIL that NPM is a subsidiary of GitHub, making this indeed Microsoft's responsibility.
belgattitude 1y ago
[dead]
feross 1y ago
Disclosure: I’m the founder of https://socket.dev 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.

by bakugo 1y ago

diggan 1y ago

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.

hfmuehleisen 1y ago

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.

belgattitude 1y ago
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
- hfmuehleisen 1y ago
  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.
  - hfmuehleisen 1y ago
    they have now removed the affected versions!
  - herpdyderp 1y ago
    At least one thing is clear from this week: npm is too slow to respond.
    - diggan 1y ago
      > 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-top-priority/ 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-security-above-all-else/ 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.
      - zahlman 1y ago
        TIL that NPM is a subsidiary of GitHub, making this indeed Microsoft's responsibility.

belgattitude 1y ago

[dead]

feross 1y ago

Disclosure: I’m the founder of https://socket.dev 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.