Live data from Hacker News

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

tane.dev

81–90 of 235 posts

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

#81
post #6

I think if somebody wants to see library distribution channels tightened up they need to be very specific about what they would like to see changed and why it would be better, since it would appear that the status quo is serving what people actually want - being able to create and upload packages and update them when you want. > But right now there are still no signed dependencies and nothing stopping people using AI…

What are you talking about, NPM keeps having issues that "status quo" of other platforms doesn't.

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

#82
post #7

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

It's a popularity issue; npm is an easy target. I don't see why it wouldn't happen to golang for example. You just need take over the git repo it's over for all users upgrading like npm

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

#83

Here's a short recap of what you can do right now, because changing the ecosystem will take years, even if "we" bother to try doing it. 1. Switch to pnpm, it's not only faster and more space efficient, but also disables post-install scripts by default. Very few packages actually need those to function, most use it for spam and analytics. When you install packages into the project for the first time, it tells you what…

Bubblewrap seems excellent for Linux uses - on macOS, it seems like sandbox-exec could do some (all?) of what bubblewrap does on Linux. There's no official documentation for SBPL, but there are examples, and I found sandboxtron[0] which was a helpful base for writing a policy to try to contain npm

0: https://github.com/lynaghk/sandboxtron/tree/main

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

#84
post #45
post #39

Earlier quoted context omitted.

Yes, but even in those domains those projects are minorities and in many examples they make it effectively impossible to legally fund or contribute to them from the side of corporations.

Why is it legally impossible to fund or contribute? Do they turn down contributions from paid developers? Do they refuse donations or just have no no mechanism for accepting them? Do they not have any form of commercial services or licence? I think there are very few projects that do not accept support in any form.

In most cases they need to be able to issue a commercial invoice in a region compatible with company accounting.

For a lot of single developers that's not a thing they're ready or able to do. Those that can, usually have companies established as a revenue source for their OSS project.

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

#85
post #19
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.

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…

That's fine. There's no requirement to "contribute back". Respect the license terms and don't go demanding anything unless you have a support contract and don't expect that you can get a support contract. It's fine to just use something as long as you also don't harass the maintainer as if they owed you something.

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

#86

Earlier quoted context omitted.

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…

I mean quite often access based errors are very opaque, I mean it is for good reason, but when you're new to something it's one of those things that leads you to give up. You want to write code, not spend 3 hours figuring out why your token doesn't work.

Security things will get hacked on later, but again it will cause all kinds of problems because the ecosystem wasn't built for it.

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

#88
post #7

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

This is funny but ultimately a mischaracterization of a popularity contest. Node culture is extreme–perhaps pathological–about using many dependencies to work around the limited standard library but the same kind of attacks happen everywhere people are releasing code. The underlying problem is that once you release something it takes only seconds before someone else can be running your code with full privileges to access their account.

That’s why the joke doesn’t really work: America is a huge outlier for gun violence because we lack structural protections. Australia doesn’t have fewer attacks in proportion to a smaller population, they have a lower rate of those attacks per-capita because they have put rules in place to be less of a soft target.

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

#89
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.

[flagged]

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

#90
post #82
post #7

"No Way To Prevent This" Says Only Package Manager Where This Regularly Happens

It's a popularity issue; npm is an easy target. I don't see why it wouldn't happen to golang for example. You just need take over the git repo it's over for all users upgrading like npm

What about Java's Maven, much more popular and longer living?
Post reply on HN