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

221–230 of 235 posts

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

#221

Post by felixgallo »

acdha wrote: post #183
felixgallo wrote: post #116

Earlier quoted context omitted.

it's not clear that the solution to this problem is to create several additional layers of barn doors.

That doesn’t make sense: it’s like arguing that it wasn’t useful to have boat design switch to compartmentalization in addition to trying to avoid hitting things. You can spend a lot of effort trying to ensure bad code never arrives but unless that’s perfect you also want to think about how to make it less catastrophic.

the proposed idea does not reduce the attack surface or make anything easier or less catastrophic.

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

#222

Post by tcoff91 »

austin-cheney wrote: post #146
tcoff91 wrote: post #78

Earlier quoted context omitted.

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.

This sounds like blaming the victim. How do you on one hand call these people engineers, as if they are engineering something, and then on the other hand blame everything else for their inability to perform? That is weird. Its just a software platform. Would you really blame society for being too harsh if doctors, lawyers, police, teachers cannot do their jobs? It is weird to see so many people blame the web platform…

The web is not an application platform, it’s a document rendering platform that has been hacked together to be an application platform.

Without libraries it’s incredibly hard to be productive building applications. It’s only with dependencies that the web becomes an acceptable application platform.

Look at how much JS it takes to implement a material-ui textfield that automatically grows and shrinks. Building a date picker is a pain in the ass. Making sure those things follow all the arcane aria standards to be accessible is difficult. There’s no good reason why everyone should have to rebuild their own date picker.

Without libraries the web is the hardest application platform to use by far if you are trying to build actual apps and not just websites with content.

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

#223

Post by zkochan »

Hexshin0bi wrote: post #217
homebrewer wrote: post #25

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…

"...but also disables post-install scripts by default." in pnpm docs it says: """ enablePrePostScripts Default: true Type: Boolean When true, pnpm will run any pre/post scripts automatically. So running pnpm foo will be like running pnpm prefoo && pnpm foo && pnpm postfoo. """ am i missing something here?

enablePrePostScripts is about running "prebuild" and "postbuild" scripts automatically, when you run "pnpm run build"

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

#224

Post by zkochan »

zkochan wrote: post #223
Hexshin0bi wrote: post #217

Earlier quoted context omitted.

"...but also disables post-install scripts by default." in pnpm docs it says: """ enablePrePostScripts Default: true Type: Boolean When true, pnpm will run any pre/post scripts automatically. So running pnpm foo will be like running pnpm prefoo && pnpm foo && pnpm postfoo. """ am i missing something here?

enablePrePostScripts is about running "prebuild" and "postbuild" scripts automatically, when you run "pnpm run build"

well, it is literally in an example in the text that you provided. So, I am not sure why you confused it with postinstall lifecycle scripts.

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

#225

Post by JanneVee »

tcoff91 wrote: post #49
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.

20 of the packages were from Crowdstrike

I'm dumbstruck that Crowstrike exists with George Kurtz still at the helm. There is no accountability at all. Kurtz was CTO of McAfee when their update caused back in 2010. Why does these things keep following him?

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

#226

Post by acdha »

felixgallo wrote: post #221
acdha wrote: post #183

Earlier quoted context omitted.

That doesn’t make sense: it’s like arguing that it wasn’t useful to have boat design switch to compartmentalization in addition to trying to avoid hitting things. You can spend a lot of effort trying to ensure bad code never arrives but unless that’s perfect you also want to think about how to make it less catastrophic.

the proposed idea does not reduce the attack surface or make anything easier or less catastrophic.

You might want to reread more carefully. Using the OS security features to restrict what the code you just installed can do prevents immediate attacks and gives you a chance to notice suspicious activity. If the only way to read a file is for the package to request permission and a scope, that gives you a chance to notice it (huh, why does tiny-color need ~/.GitHub?) and also serves as a triage cue for scanning pipelines to flag updates, especially minor ones, which increase the scope of the requested permissions.

Using OS features to restrict access to sensitive data similarly gives you another chance to detect a compromise because a denied operation to, say, read your wallet by an app which doesn’t need to is both highly visible and unambiguous.

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

#227

Post by felixgallo »

acdha wrote: post #226
felixgallo wrote: post #221

Earlier quoted context omitted.

the proposed idea does not reduce the attack surface or make anything easier or less catastrophic.

You might want to reread more carefully. Using the OS security features to restrict what the code you just installed can do prevents immediate attacks and gives you a chance to notice suspicious activity. If the only way to read a file is for the package to request permission and a scope, that gives you a chance to notice it (huh, why does tiny-color need ~/.GitHub?) and also serves as a triage cue for scanning pipel…

I can read, thank you. The specific problems are that your 'prevent immediate attacks' and 'gives you a chance' are both doing significantly more work than you'd like to admit. A large project can use hundreds of npm packages, with the total dependency tree in the thousands. Your choices are to either give them infinite dialog fatigue on every single npm update, or make security-weakening tradeoffs. And if you ever let any of the packages create a new window and draw to it, that's game over. Even without malicious dialogs, users will continue to make bad choices, and 99.9% of all non-developer users and 99.8% of all developer users will accept or even broaden insecure defaults when prompted.

The problem is coming from inside the house.

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

#228

Post by austin-cheney »

tcoff91 wrote: post #222
austin-cheney wrote: post #146

Earlier quoted context omitted.

This sounds like blaming the victim. How do you on one hand call these people engineers, as if they are engineering something, and then on the other hand blame everything else for their inability to perform? That is weird. Its just a software platform. Would you really blame society for being too harsh if doctors, lawyers, police, teachers cannot do their jobs? It is weird to see so many people blame the web platform…

The web is not an application platform, it’s a document rendering platform that has been hacked together to be an application platform. Without libraries it’s incredibly hard to be productive building applications. It’s only with dependencies that the web becomes an acceptable application platform. Look at how much JS it takes to implement a material-ui textfield that automatically grows and shrinks. Building a date…

> Look at how much JS it takes to implement a material-ui textfield that automatically grows and shrinks.

I would do that with CSS.

> Building a date picker is a pain in the ass. Making sure those things follow all the arcane aria standards to be accessible is difficult.

If you want to display a visual calendar then yes, mostly. However, if instead you make date picking relative to now then it becomes very simple. It’s just adding or subtracting numbers from Date.now(). You can even produce date spans super easily.

I understand where you are going. When everything starts from a visual UI perspective the code is just an implementation detail except that it’s dense. If instead you start at from the implementation perspective of how it really works at the lowest level then everything just appears step by step. Nobody starts building beautiful skyscrapers from the visual exterior first. No, they lay the foundation, a boring slab of concrete around some grounding poles.

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

#229

Post by arianvanp »

madeofpalk wrote: post #75
shakna wrote: post #57

Earlier quoted context omitted.

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

Trusted publishing helps with tracking down how something got compromised after compromise. It doesn't do anything to protect against compromise except for using time-limited credentials but that only makes the window smaller. It doesn't make compromise impossible

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

#230

Post by sarchertech »

marcosdumay wrote: post #189
sarchertech wrote: post #176

Earlier quoted context omitted.

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…

Open source is open source. There exists no gradient there. If your software isn't open source, don't claim it is. You are free to try to normalize your licensing preferences. Even better if you have a nice name for them that don't try to mislead people into thinking they are something they clearly aren't. > I think the world would be a much better place if we just changed the definition of open source to include suc…

If OSI wants to police a phrase they can come up with something original that they can trademark.

>Open source is open source. There exists no gradient there.

Of course there does. If there wasn't a gradient there wouldn't be so many different licenses, there wouldn't be a huge debate anytime on HN anytime someone brings up the definition of open source, and there wouldn't be people constantly arguing about whether licensing requirements constitute restrictions.

OSI is just some group funded by initially by Tim O'Reilly (but now by, Google, MS, Intel and the rest of big tech) to co-opt the free software movement and turn it into something business friendly. They took an already in use phrase, built an ad campaign around it and added a specific bullet point to the definition that said you can't restrict open source software from commercial use.

>Normal and everyday use of "open source" does absolutely not include the licenses you are talking about.

I guarantee you that the majority of people using the term "open source" are using something closer to the dictionary definition than the OSI definition. The average software developer has never even read the OSI definition.

The dictionary definition is

"denoting software for which the original source code is made freely available and may be redistributed and modified."

Nothing in this precludes banning Nazis, or large businesses, or certain governments from using it.

The OSI definition includes that, but adds some technical specifics--one of which is that there can't be "discrimination between uses, including commercial use".

If you want to use the phrase "OSI approved open source", that's fine, but there's a reason OSI doesn't have a trademark for the term. They don't own it. Tim O'Reilly can kick rocks with this word policing.

Post reply on HN