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

171–180 of 235 posts

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

#171

Post by austin-cheney »

user34283 wrote: post #141
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?

It boils down to him feeling superior to web developers, who are far beneath him and couldn't possibly program with other tools.

Actually, its the opposite. When you are no longer compatible to the workforce because you don't want waste all your time on the same basic literacy things over and over you start to feel extremely inferior when you cannot get a job.

But the fact the concerns of superiority come up so repeatedly just serves to illustrate how much insecurity is baked into the workforce. Confident people don’t worry about high confidence in other people.

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

#172

Post by [deleted] »

ants_everywhere wrote: post #70
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.

> 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. People who work on permissively licensed software are donating their time to these Fortune 500 companies. It hardly seems fair to call the companies leeches for accepting these freely given donations.

[deleted]

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

#173

Post by thayne »

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.

In the case of npm though it is run by a very wealthy company: Microsoft.

But also, most OSS Software is provided without warranty. Commercial companies should either be held accountable for ensuring the open source components are secure or paying someone (either the maintainer directly, or a third party distributor) to verify the security of the component.

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

#174

Post by amiga386 »

h1fra wrote: post #158
amiga386 wrote: post #127

Earlier quoted context omitted.

As far as I remember: "go get" doesn't execute downloaded code automatically; there's no "postinstall" script (there can be a manual "go generate" or "go tool" the user may run) Go doesn't upgrade existing dependencies automatically, even when adding a new dependency: you need an explicit "go get -u" You don't use the same tool to both fetch and publish ("go get" vs "git push") so it's less likely a module publisher…

postinstall is a liability for sure, but as soon as you execute untrusted code, it's the same no matter the language. Last week, npm pawn was working like this without a postinstall, which could be the same with Go. Nothing prevents me from pushing a code that would read all your files as soon as you load the library in your code.

I notice you didn't address the other 4 differences. All 5 are about "defence in depth", making things less likely - and conversely, not doing them makes pwning more likely.

I'll add a 6th difference: "go get" downloads source code, not maintainer-provided tarballs. You can't sneak extra things in there that aren't in the code repo.

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

#175

Post by sarchertech »

Chris2048 wrote: post #149
sarchertech wrote: post #101

Earlier quoted context omitted.

>expecting nothing in return Let’s ignore that no one contributes to open source expecting nothing in return. I can help someone out expecting nothing in return. Then if my situation changes and I need help, but they look at me and say “sorry your help was a gift so I’m not going to return the favor even though I can”. That person is a dick. The problem is you are taking the act of applying a permissive license as so…

> I can help someone out expecting nothing in return. Then if my situation changes It sounds like you did expect something in return, conditional on your circumstances. Maybe it's good-will or something, but some kind of social insurance in any case.

This is partly getting into questions about whether “pure” altruism is even possible, e.g., is an anonymous donation truly selfless if you do it because it makes you feel good.

But in the example above it’s entirely possible that you helped someone out with no expectation of being paid back. Let’s say you’re rich and the person you helped is a chronic drug addict. You have no expectation of every needing help and no expectation that the person you helped will ever be in a position to help you.

Let’s say I give a homeless person a dollar. He turns around and uses that dollar to buy a lottery ticket and wins 100 million dollars. Years later, I’m homeless and the former homeless guy walks past me and gives me a lecture about how I should have put conditions on my donation.

In that situation there was no reasonable expectation for anything except as you said maybe good will. But of course open source developers also expect good will.

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

#176

Post by sarchertech »

marcosdumay wrote: post #164
sarchertech wrote: post #28

Earlier quoted context omitted.

Just because you can do something doesn’t mean you should. There’s also lot of pressure for devs not to use licenses that restrict use by large companies. Try adding something to your license that says companies making over $10 million per year in revenue have to pay, and half of the comments on show HN will be open source warriors either asking why you didn’t use a standard license or telling you that this isn’t ope…

> telling you that this isn’t open source Are you talking about promoting some software as open source when it's in fact not? Because yes, there's something wrong with that, you shouldn't do it, and people will rightfully react loudly if you try. People don't complain about proprietary software honestly communicated as that.

This is exactly the kind of thing, I’m talking about. Open source has mostly been captured by large corporations because purists refuse to recognize the gradient between proprietary and completely free.

If I license my software as MIT but with an exception that you can’t use it for commercial purposes if you make more than $100 million a year in revenue, that’s a lot closer to open source than proprietary.

We should be normalizing licenses that place restrictions on large corporations.

I think the world would be a much better place if we just changed the definition of open source to include such licenses. We don’t even really need to change the definition because normal everyday use of the term would already include them.

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

#177

Post by ankit_mishra »

aj_g wrote: post #11

Anyone have a good solution to scan all code in our Github org for uses of the affected packages? Many of the methods we've tried have dead ended. Inability to reliably search branches is quite annoying here.

npm audit - will tell you if there's any packages with known vulnerabilities. https://docs.npmjs.com/cli/v11/commands/npm-audit I'd imagine it's considerably slower than search, but hopefully more reliable.

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

#178

Post by apimade »

madeofpalk wrote: post #76
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?

Accidentally installing a malicious package in your dev environment, the concern isn’t “what’s already installed”, it’s what’s potentially going to be installed in the future by you or your colleagues.

So, you pin the version and update periodically when security issues arise in your dependencies.

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

#179

Post by tanepiper »

czbond wrote: post #170
tanepiper wrote: post #155

Earlier quoted context omitted.

Oh I agree - it's far too late to make major changes. When they took over, they had the opportunity to drive a new roadmap towards a more secure solution. 2FA isn't a solution to security, it's a solution to hinder and dissuade low-effort hackers from compromising accounts - it's still subject to social engineering (like spearphishing). I tend to agree with your broader point - sandboxing will be the way to go, I've…

I have come to using a multi stage Docker build. One to install dependencies and build whatever it is. I then might have a second clean docker image where the dependencies are copied to and run. This helps with localized risk, and some production risk - but not all of it. NPM packages have become a huge nuisance security wise.

Yes, also using multi-stage container - we output signed OCI to our repository and have Rekor and GitHub for SBOM and attestation.

This is another huge pet peeve of mine is how hard it is to have a good container pipeline to build containers without running root - we tried some of the alternatives but they all had drawbacks - easiest is to just use GitHub Ubuntu images and hope for the best (although I recently saw some improvement in this area we want to investigate)

Post reply on HN