Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh no, not again a meditation on NPM supply chain attacks

tane.dev

Post reply on HN
Print view View original

71–80 of 235 posts

Re: Oh no, not again a meditation on NPM supply chain attacks

#71

Post by snickerdoodle14 »

brookst wrote: post #68
snickerdoodle14 wrote: post #60

Earlier quoted context omitted.

Not really, those technologies are basically designed to be able to enforce DRM remotely. Secure Enclave = store the encryption keys to media in a place where you can't get them Secure Boot = first step towards remote attestation so they can remotely verify you haven't modified your system to bypass the above Advertising rules the world.

How is that different? Is there such a thing as secure hardware that can prevent supply chain attacks (by enabling higher layers to guarantee security) and secure hardware that prevents copying data (by enabling higher layers to guarantee security)?

Sure. Malware tends not to have physical hands that can touch the machine and any buttons attached to it. Physical ownership should be true ownership, but they're taking that away from you.

Re: Oh no, not again a meditation on NPM supply chain attacks

#72

Post by acdha »

stingraycharles wrote: post #55
grafmax wrote: post #52

Earlier quoted context omitted.

Technology is insecure all the way down to the hardware. The structural cause of this is that companies aren’t held liable for insecure products, which are cheaper to build. So companies’ profit motives contribute to this mess not just through the exploitation of open source labor (as you describe) but through externalizing security costs as well.

Isn’t all this stuff with Secure Enclave supposed to address these kind of things? It’s my take that over the past ~ decade a lot of these companies have been making things a lot better, Windows even requires secure boot these days as well.

They’re not the same problems. The Secure Enclave protects things like your biometrics, hardware-backed keys (e.g. on a Mac, WebAuthn and iCloud Keychain), and the integrity of the operating system but not every bit of code running as your account. That means that an NPM install can’t compromise your OS to the point that you can’t recover control, but it means the attacker can get everything you haven’t protected using sandbox features.

That’s the path out of this mess: not just trying to catch it on NPM but moving sensitive data into OS-enforced sandboxes (e.g. Mac containers) so every process you start can’t just read a file and get keys, and using sandboxing features in package managers themselves to restrict when new installs can run code and what they can do (e.g. changing the granularity from “can read any file accessible to the user” to “can read a configuration file at this location and data files selected by the user”), and tracking capability changes (“the leftpad update says it needs ~/.aws in this update?”).

We need to do that long-term but it’s a ton of work since it breaks the general model of how programs work we’ve used for most the last century.

Re: Oh no, not again a meditation on NPM supply chain attacks

#73

Post by brookst »

ricardobeat wrote: post #53
sarchertech wrote: post #47

Earlier quoted context omitted.

> This implies some kind of fairness/moral contract in a license like MIT. The license tells you what you are legally allowed to do. It doesn’t supersede basic concepts of fairness. The average person would say that if you directly make millions of someone else’s work, the fair thing to do is to pay that person back in some way. Calling someone a leech is just saying that they aren’t following the the accusers model…

> someone else’s work It is not “their” work anymore (IP rights discussions aside) once they published with an unrestricted license. That’s the point. You do it expecting nothing in return, and do it willingly. Expecting “fairness” is a misunderstanding of the whole spirit of it.

Semantic games with “their work”. An artist who sells a painting can still call it their work, even if someone else owns it. And I suppose the collector who bought it could also call it their work, though that phrasing isn’t usually used.

It comes about because “work” is overloaded to mean both the activity of creating and the product/result of that activity.

Re: Oh no, not again a meditation on NPM supply chain attacks

#74

Post by ants_everywhere »

tanepiper wrote: post #63
cube00 wrote: post #2

> The tools we use to build software are not secure by default, and almost all of the time, the companies that provide them are not held to account for the security of their products. The companies? More like the unpaid open source community volunteers who the Fortune 500 leech off contributing nothing in return except demands for free support, fixes and more features.

Author of the article here - holistically this isn't just about NPM dependencies, it's the entire stacks we work with. Cloud vendors provide security, but out of the box they don't provide secure platforms - a lot of this is left up to developers, without security experts - this is dangerous - I have 25 years of experience and I wouldn't want to touch the depths of RBAC. SaaS products don't enforce good security - I'…

> Cloud vendors provide security, but out of the box they don't provide secure platforms - a lot of this is left up to developers, without security experts -

A lot of the spread of Shai-Hulud is due to s having overly broad credentials on NPM, GitHub and elsewhere. It's not that NPM doesn't support scoped credentials, it's that developers don't want to deal with it so it's not the default. There's no reason why, for example, a developer needs a live credential to publish their package when they're just hacking on code.

This is related to the `curl | bash` pattern. Projects like NPM want to make it easy to get started and hard to reach a failure case so they sacrifice well-known security practices during the growth phase.

Re: Oh no, not again a meditation on NPM supply chain attacks

#75

Post by madeofpalk »

shakna wrote: post #57
andrewl-hn wrote: post #26

Earlier quoted context omitted.

TBF it does happen to other package managers, too. There were similar attacks on PyPI and Rubygems (and maybe others). However, since npm is the largest one and has the most packages released, updated, and downloaded, it became the primary target. Similar to how computer viruses used to target Windows first and foremost due to its popularity. Also, smaller package managers tend to learn from these attacks on npm, and…

PyPI is working towards attestation [0], and already has "Trusted Publisher" [1]. Ruby has had signed gems since v2 [2]. These aren't a panacea. But they do mean an effort has been made. npm has been talking about maybe doing something since 2013 [3], but ended up doing... Nothing. [4] I don't think it's fair to compare npm to the others. [0] https://docs.pypi.org/attestations/producing-attestations/ [1] https://docs…

NPM has both Trusted Publishing and provenance claims for where packages are built.

https://docs.npmjs.com/trusted-publishers

https://docs.npmjs.com/generating-provenance-statements

Trusted Publishing is relatively new - GA-ed in July https://github.blog/changelog/2025-07-31-npm-trusted-publish...

Re: Oh no, not again a meditation on NPM supply chain attacks

#76

Post by madeofpalk »

apimade wrote: post #40

Here’s a one-liner for node devs on MacOS, pin your versions and manually update your supply chain until your tooling supports supply chain vetting, or at least some level of protection against instantly-updated malicious upstream packages. Would love to see some default-secure package management / repo options. Even a 24 hour delayed mirror would be better than than what we have today. find . -name package.json -not…

? Package lock files from npm/yarn/pnpm automatically lock all your dependencies (including transitive deps)

What does this actually achieve?

Re: Oh no, not again a meditation on NPM supply chain attacks

#77

Post by watwut »

MrGilbert wrote: post #48
giantg2 wrote: post #19

Earlier quoted context omitted.

I remember joining my company right out of college. In the interview we started talking about open source since I had some open source Android apps. I asked if the company contributed back to the projects it used. The answer was no, but that they were planning to. Over a decade later... they finally created a policy to allow commits to open source projects. It's been used maybe 3 times in it's first year or so. Nobod…

> Nobody has the time I'd erase that part entirely, as it is not true, from my point of view. My day, as has every other person's day, has exactly 24 hours. As an employee, part of that time is dedicated to my employer. In return, I receive financial compensation. It's up to them to decide how they want to spend the resources they acquired. So yes, each and every company could, in theory, contribute back to Open Sour…

> In a highly capitalized world, where share holder value is more worth than anything else, there are only a few companies that do the right call and act responsible.

It is not just that. In a well functioning theoretical free market, no one is going to have time either. The margins are supposed to end up being tight and the competition is supposed to weed out economic inefficiency. Voluntary pro-social behavior is a competitive disadvantage and an economic inefficiency. So, by design, the companies end up not "having time for that".

You need a world that allows for inefficiency and rewards pro-social behavior. That is not the world where we are living in currently.

Re: Oh no, not again a meditation on NPM supply chain attacks

#78

Post by tcoff91 »

austin-cheney wrote: post #54
pavel_lishin wrote: post #29

Earlier quoted context omitted.

> Consider how many JavaScript developers are completely unemployable without that free software. Can you say more about this?

[flagged]

I think that ultimately it’s the fault of the web platform.

With just a bit of retraining those engineers that could not be productive without a ton of npm packages could ship an iPhone app written in Swift.

JS’ standard library is abysmal.

Re: Oh no, not again a meditation on NPM supply chain attacks

#79

Post by izacus »

austin-cheney wrote: post #38
watwut wrote: post #22

Earlier quoted context omitted.

Per survey I read, majority of open source is created by people who are paid for it. The unpaid volunteer working full time on something is effectively a myth.

I don’t think that is correct. VS Code developers and the TypeScript team is paid by MS. Core of React is paid by Meta, or was. Java language is paid by Oracle as is the LiberaSuite and MySQL. Most of the Linux foundation projects, which includes Node are volunteers. Most of the Apache foundation software is from volunteers. Most NPM packages are from volunteers. OpenSSL is volunteers. There is also a big difference…

Most of those "voluneers" are also developing those projects as part of their paid job in a form of company contribution back to OSS though.

Re: Oh no, not again a meditation on NPM supply chain attacks

#80

Post by watwut »

josephg wrote: post #56
watwut wrote: post #22

Earlier quoted context omitted.

Per survey I read, majority of open source is created by people who are paid for it. The unpaid volunteer working full time on something is effectively a myth.

I’ve contributed a huge amount of opensource code over my career - almost all of it entirely unpaid. I don’t know the statistics, but I know many other people who have done the same. I think there are a lot of high profile opensource projects which are either run by corpos (like React) or have a lot of full time employees submitting code (Linux). But there’s an insanely long tail of opensource projects on npm, cargo,…

npm was a company for years now. It was initially created as a volunteer one person project, then they create company 10 years ago and eventually sold to Github which was sold to Microsoft. It has spent more time being developed as a paid thing then by unpaid volunteers doing it on the side.
Post reply on HN