3 ms·

In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about i

In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintainer side: - MFA for publishing: https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification https://docs.npmjs.com/requiring-2fa-for-package-publishing-... - trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers And as of recently, staged publishing, essentially combining the best of both those features: https://docs.npmjs.com/staged-publishing https://docs.npmjs.com/staged-publishing Now you can: - Publish from CI, without static credentials - AND require a maintainer to approve it using MFA before it actually goes live to the registry If you want you can still use something like GitHub Actions Environments protection to require multiple approvals, or a time delay, on the CI side. We need to encourage the community to adopt these publishing protections or this will continue to be an issue.

selckin 4mo ago
they need to make it required for everyone, and then they'll have done something
ajross 4mo ago
IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate already-trusted upstreams for packages, it's that the upstreams cannot be trusted as the sole source for security at all. Upstreams are a bunch of hackers[1] who aren't really interested in, nor will ever be good at, solid release engineering practices. But some people are! The solution in the Linux world (and the one that saved us from xz-utils) is that there is a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users. These people have different eyes, different consumer requirements and different quality metrics. And they catch bugs and malfesance that the upstreams aren't prepared to do. NPM (and cargo/PyPI et. al.) continues to think it can short circuit this requirement for human labor. It can't. [1] In NPM's particular ecosystem, a bunch of web jockeys used to extremely fast release processes, loose compatibility requirements, and extreme reliance on reuse. This really explains why we see this with node packages more than Python or Rust: older and more conservative programmers just don't have as many rakes to step on.
- simpaticoder 4mo ago
  > The solution in the Linux world ... is that there is a second level of human beings... AKA "unpaid labor". I don't think that's a good solution, either. Certainly it's only by pure luck that no malefactors have infiltrated the ad hoc, anonymous social proof communities that Linux depends on, and I don't think other systems should emulate it. The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability.
  - nightpool 4mo ago
    There is a version of that. It is called RedHat Enterprise Linux. : )
  - ajross 4mo ago
    > Certainly it's only by pure luck that no malefactors have infiltrated the [pinko commie Linux hippy commune] Yeah... no. Sorry, that's a wild misunderstanding of the economics of the Linux ecosystem, modern libertarian thought and the employment status of people with write access to the packaging layers.
  - jruohonen 4mo ago
    > ... a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users. > The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability. That was also what I was thinking aloud a moment ago. And there would be a business opportunity, too. Perhaps not like RHEL et al. full-blown stuff per se, but say smaller scale guarantees with different pricing; web, AI, scientific computing, and whatnot. At the pace things are progressing, I'd guess you might even get desktop etc. users on board (for nominal pricing).
- AgentME 4mo ago
  But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit of that layer of review.
randusername 4mo ago
My read is that there's a crowd that is unimpressed with mechanistic changes when in their view there is a cultural issue. From the outside looking in, web dev has this frantic wild west energy to it. Mutability, dynamic typing, standards changing constantly, frameworks changing constantly, continuous delivery, CDNs, live A/B campaigns, large numbers of dependencies, sensitive user data spread out across a lot of infrastructure. I'm not saying that's an accurate view and I don't think "I told you so" is the right attitude, but I can understand the place it comes from.
michaelt 4mo ago
> - MFA for publishing: https://docs.npmjs.com/requiring-2fa-for-package-publishing- https://docs.npmjs.com/requiring-2fa-for-package-publishing-... > - trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers According to [1] "All affected packages were published via GitHub Actions OIDC from the RedHatInsights/javascript-clients repository, indicating the upstream CI/CD pipeline itself was compromised." So the malicious package would have gotten the happy little green star, with users assured it was "Built and signed with provenance." [1] https://lwn.net/Articles/1075742/ https://lwn.net/Articles/1075742/
za3faran 4mo ago
Why doesn't Java seem to have anything close to this issue? Isn't it a solved problem?
- skydhash 4mo ago
  No deep dependency graph, so easy to audit and inspect. Stable development process, so easier to manage the flow of updates. And I believe a more cautious ecosystem. Not everyone is rushing to create or adopt new libraries, especially for what could have been a single file. So most libraries are about solving a domain, not just one single algorithm. Same thing with C, Perl, PHP,…
48terry 4mo ago
> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. I mean it keeps happening lmao. You can track npm attacks these on a calendar. Someone made a npm parody of the classic "no way to avoid this" The Onion article. It's great there's work to stop it all but also... it keeps happening. I find it funny in a "here we go again" way.
- no-name-here 4mo ago
  >> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. > … the classic "no way to avoid this" The Onion article But isn't point of The Onion article that A) the US has >50x as many incidents as the rest of the developed world combined [1], and yet B) acts like there is "no way to avoid this". Does NPM have >50x as many incidents as the rest of established languages combined? Is NPM claiming there is "no way to avoid this" or are they putting in place things like automatic install delays? While all the major js package managers already support install delays, none of the big local C#/dotnet/nuget apps do (Visual Studio/Rider/nuget/dotnet/VS Code). https://github.com/NuGet/Home/issues/14657 https://github.com/NuGet/Home/issues/14657 [1] https://edition.cnn.com/2018/05/21/us/school-shooting-us-versus-world-trnd/ https://edition.cnn.com/2018/05/21/us/school-shooting-us-ver...

selckin 4mo ago

they need to make it required for everyone, and then they'll have done something

ajross 4mo ago

IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate already-trusted upstreams for packages, it's that the upstreams cannot be trusted as the sole source for security at all. Upstreams are a bunch of hackers[1] who aren't really interested in, nor will ever be good at, solid release engineering practices. But some people are! The solution in the Linux world (and the one that saved us from xz-utils) is that there is a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users. These people have different eyes, different consumer requirements and different quality metrics. And they catch bugs and malfesance that the upstreams aren't prepared to do. NPM (and cargo/PyPI et. al.) continues to think it can short circuit this requirement for human labor. It can't. [1] In NPM's particular ecosystem, a bunch of web jockeys used to extremely fast release processes, loose compatibility requirements, and extreme reliance on reuse. This really explains why we see this with node packages more than Python or Rust: older and more conservative programmers just don't have as many rakes to step on.

simpaticoder 4mo ago
> The solution in the Linux world ... is that there is a second level of human beings... AKA "unpaid labor". I don't think that's a good solution, either. Certainly it's only by pure luck that no malefactors have infiltrated the ad hoc, anonymous social proof communities that Linux depends on, and I don't think other systems should emulate it. The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability.
- nightpool 4mo ago
  There is a version of that. It is called RedHat Enterprise Linux. : )
- ajross 4mo ago
  > Certainly it's only by pure luck that no malefactors have infiltrated the [pinko commie Linux hippy commune] Yeah... no. Sorry, that's a wild misunderstanding of the economics of the Linux ecosystem, modern libertarian thought and the employment status of people with write access to the packaging layers.
- jruohonen 4mo ago
  > ... a second level of human beings responsible for reviewing, auditing, packaging, and customizing those hacker-generated upstreams for the benefit of their users. > The real solution (for Linux too) is a paid package curation service. Or really, a small handful of them competing on price, speed, reliability. That was also what I was thinking aloud a moment ago. And there would be a business opportunity, too. Perhaps not like RHEL et al. full-blown stuff per se, but say smaller scale guarantees with different pricing; web, AI, scientific computing, and whatnot. At the pace things are progressing, I'd guess you might even get desktop etc. users on board (for nominal pricing).
AgentME 4mo ago
But there is a second level of people reviewing packages on npm. They're the ones that report issues like the github issue this HN thread is linked to, and they very frequently get malicious npm packages taken down within a day of publishing. The big issue is just that not everyone is using a cooldown to avoid packages less than a day old and so people who install new packages at unlucky times don't get the benefit of that layer of review.

randusername 4mo ago

My read is that there's a crowd that is unimpressed with mechanistic changes when in their view there is a cultural issue. From the outside looking in, web dev has this frantic wild west energy to it. Mutability, dynamic typing, standards changing constantly, frameworks changing constantly, continuous delivery, CDNs, live A/B campaigns, large numbers of dependencies, sensitive user data spread out across a lot of infrastructure. I'm not saying that's an accurate view and I don't think "I told you so" is the right attitude, but I can understand the place it comes from.

michaelt 4mo ago

> - MFA for publishing: https://docs.npmjs.com/requiring-2fa-for-package-publishing- https://docs.npmjs.com/requiring-2fa-for-package-publishing-... > - trusted publishers, available for about a year: https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers According to [1] "All affected packages were published via GitHub Actions OIDC from the RedHatInsights/javascript-clients repository, indicating the upstream CI/CD pipeline itself was compromised." So the malicious package would have gotten the happy little green star, with users assured it was "Built and signed with provenance." [1] https://lwn.net/Articles/1075742/ https://lwn.net/Articles/1075742/

za3faran 4mo ago

Why doesn't Java seem to have anything close to this issue? Isn't it a solved problem?

skydhash 4mo ago
No deep dependency graph, so easy to audit and inspect. Stable development process, so easier to manage the flow of updates. And I believe a more cautious ecosystem. Not everyone is rushing to create or adopt new libraries, especially for what could have been a single file. So most libraries are about solving a domain, not just one single algorithm. Same thing with C, Perl, PHP,…

48terry 4mo ago

> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. I mean it keeps happening lmao. You can track npm attacks these on a calendar. Someone made a npm parody of the classic "no way to avoid this" The Onion article. It's great there's work to stop it all but also... it keeps happening. I find it funny in a "here we go again" way.

no-name-here 4mo ago
>> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair. > … the classic "no way to avoid this" The Onion article But isn't point of The Onion article that A) the US has >50x as many incidents as the rest of the developed world combined [1], and yet B) acts like there is "no way to avoid this". Does NPM have >50x as many incidents as the rest of established languages combined? Is NPM claiming there is "no way to avoid this" or are they putting in place things like automatic install delays? While all the major js package managers already support install delays, none of the big local C#/dotnet/nuget apps do (Visual Studio/Rider/nuget/dotnet/VS Code). https://github.com/NuGet/Home/issues/14657 https://github.com/NuGet/Home/issues/14657 [1] https://edition.cnn.com/2018/05/21/us/school-shooting-us-versus-world-trnd/ https://edition.cnn.com/2018/05/21/us/school-shooting-us-ver...