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

'No way to prevent this,' says only package manager where this regularly happens

kevinpatel.xyz

Post reply on HN
Print view View original

131–140 of 230 posts

Re: 'No way to prevent this,' says only package manager where this regularly happens

#131

Post by dns_snek »

827a wrote: post #88
raggi wrote: post #39

Earlier quoted context omitted.

install scripts are a distraction, just like package signatures are a distraction. adding/removing either feature has no significant impact on the wormability of this package ecosystem. installed npm code is run, with nearly zero exceptions.

> There's a huge difference, because postinstall scripts are almost guaranteed to run in your CI pipeline. Compromised code probably won't (maybe it will if your test cases test a compromised package). Different attack profile. Worse in some ways (your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm) (your CI pipeline also likely has some level of priv…

> Compromised code probably won't (maybe it will if your test cases test a compromised package).

Code runs automatically on import, you don't have to call dependency.infectMePlease()

Your code imports depA which imports depB which imports depC which imports depD which has been compromised, and boom, malicious code runs before you've even finished resolving the imports.

> your CI likely has NPM push tokens, which is how this single-package worm become a multi-package self-replicating worm

I've never once seen or worked with a CI pipeline that ran "npm install" that would be any safer if post-install scripts didn't exist. They all run "npm run test" or similar.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#132

Post by chadgpt3 »

com2kid wrote: post #82
brunoborges wrote: post #80

Earlier quoted context omitted.

That is another important layer. Maven Central is not immune to credential theft. If a publisher token is stolen, an attacker may still be able to publish a malicious new version until the token is revoked or the account is suspended after reporting the problem to Sonatype. But in the Maven/Gradle ecosystem, most projects pin exact dependency versions. Support for version ranges and dynamic versions exist, but they a…

> Enforce scope (namespace) requirement, and require external verification (reverse DNS for example). Who the heck says everyone who publishes a library has a domain? That seems absurd.

Why don't you? It costs around $20 per year. Every serious computer nerd should have one, and a web server with at least a basic homepage.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#133

Post by chadgpt3 »

adamnemecek wrote: post #61
amluto wrote: post #56

Earlier quoted context omitted.

There is also not too much legitimacy to the fact that Rust packages can run unsandboxed when they build themselves.

I feel like it's harder to hide malicious stuff in Rust build scripts.

Why?

Re: 'No way to prevent this,' says only package manager where this regularly happens

#134

Post by otabdeveloper4 »

saghm wrote: post #66
apothegm wrote: post #47

Earlier quoted context omitted.

Why Python, tho, in that case? Its stdlib is quite robust. Surprisingly so in some areas.

I'm not convinced that Python should be the standard for package management either. Earlier this week I was trying to publish a Python package for the first time wrapping a Rust library I wrote (for use only on Linux and Python 3.12+), and it literally took me hours to get from "I have a wheel that I can import and it works on my system" to "I have published that wheel and can install the package from PyPI on the set…

> Python should be the standard for package management

Python is the antistandard for package management. Or maybe even the eldritch horror of package management.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#135

Post by dns_snek »

throwaway27448 wrote: post #48
raggi wrote: post #39

Earlier quoted context omitted.

install scripts are a distraction, just like package signatures are a distraction. adding/removing either feature has no significant impact on the wormability of this package ecosystem. installed npm code is run, with nearly zero exceptions.

Surely every layer of defense in depth is a distraction except the one that prevents the problem.

It's not defense in depth if the mechanism is trivially bypassed.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#136

Post by lucketone »

llbbdd wrote: post #125
bichiliad wrote: post #85

Earlier quoted context omitted.

Why would you even imply something like that?

They feel the need to compete given that jokes about "backend" devs write themselves

Frontend has lower barrier of entry and more appeal for beginners, so its bell curve might have its left edge is thicker. It impacts the avg of problems and culture of dealing with them

Re: 'No way to prevent this,' says only package manager where this regularly happens

#137

Post by youre-wrong3 »

eranation wrote: post #64

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…

NPM doesn’t make it easy to do cooldowns because their apis prevent it.

Re: 'No way to prevent this,' says only package manager where this regularly happens

#138

Post by tkel »

10000truths wrote: post #122
joeblubaugh wrote: post #51

There has been a lot of pain at my various jobs installing a safe global npm config on every developer machine, asking people not to disable it, checking it with mdm tools. A safer out-of-the-box configuration is long overdue.

What do you mean by safe config? If you're trying to mandate a cooldown period or a whitelist/blacklist of packages, the correct approach is to configure a company-controlled registry that pulls from the upstream npm registry while enforcing your desired policies.

Or even just a proxy that can enforce the constraints

Re: 'No way to prevent this,' says only package manager where this regularly happens

#139

Post by oneshtein »

eranation wrote: post #64

I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cooldowns? Most npm (or pypi) compromises were taken down within hours, cooldowns simply mean - ignore any package with release date younger than N days (1 day can…

Why not to create a separate distribution or channel (bleeding edge/stable/long term), like Linux distributions do?

Re: 'No way to prevent this,' says only package manager where this regularly happens

#140

Post by whatevaa »

chadgpt3 wrote: post #132
com2kid wrote: post #82

Earlier quoted context omitted.

> Enforce scope (namespace) requirement, and require external verification (reverse DNS for example). Who the heck says everyone who publishes a library has a domain? That seems absurd.

Why don't you? It costs around $20 per year . Every serious computer nerd should have one, and a web server with at least a basic homepage.

$20 per year on US is not the same value across the world. Would you say $60 per year is ok too, if you adjusted for income? 100$?

Don't count other people money.

Post reply on HN