Hacker News Reader

Comment by jraph | Hacker News Reader

npm install is such a scary command these days (or yarn install, same thing). I never liked it because of the shitload of dependencies it usually pulls but now I would hesitate running it outside a well isolated container.

This event added to the strong distrust I came to have on NPM these last months. The NPM ecosystem seems incredibly immature and unreliable and any Javascript project depending on NPM is now a potential future malware.

By the way, does anyone know an easy way to use Svelte without depending on NPM? Because if not I might reconsider my choice of using it in a side project despite me liking it.

In theory the same things could happen for PIP, Maven, Gradle, their Rust and Go counterpart and any such package manager. Any data on this?

View on HN

> In theory the same things could happen for PIP, Maven, Gradle, their Rust and Go counterpart and any such package manager. Any data on this?

Supply chain attacks, such as these, can definitely happen to any language. NPM seems to be a nice target simply because the volume of deps your avg 'simple' node project has (I mean, 'npm generate'ing a simple strapi-backed static site for us and there's ~300mb of node_modules...).

There's not really a cure. You can peg your deps to a version, but with that much code in there, you're never going to really know if that version is compromised.

If you can come up with a solution, there's money to be made..

Edit: The best we really have atm is just scanning for known vulns with stuff like xray/lifecycle/dependabot. Better than nothing, but for sure there are malicious packages out there yet to be discovered.

It can be a problem in any language or package manager but in my Golang project, I have a single dependency outside of the standard library, in my Javascript project I conservatively have 200+ (if I consider all the packages installed by my primary dependencies). The surface area is just that much bigger and the packages change so frequently.

So you recon a better (bigger?) node stdlib would solve a lot of this?

Probably, yes. I'd say most mature tech stacks provide most of what you are likely to need first party. .NET is an incredible ecosystem for this: Nearly everything the standard developer needs is available from Microsoft, most common third party packages you might want to pull in were authored by an enterprise company with support available, and if you're pulling in something by an individual, it's probably pretty niche.

That Golang project also likely isn’t trying to be a highly interactive UI running on thousands of different runtime configurations.

> In theory the same things could happen for PIP, Maven, Gradle, their Rust and Go counterpart and any such package manager. Any data on this?

in theory, but why is it always node.js/npm? I work on completely different things... is it a different community culture? is it the thousands of tiny low quality packages people include to do the most basic things?

I think in large part is there’s a higher focus on modularization in Node.JS which leads to lots more dependencies. That increases the attack vector and makes a supply chain attack easy because all it takes is a single malicious author to break trust in a chain of hundreds of packages. For example a code base I work on currently has over 250+ 3P dependencies, not because we import that many deps but because the dep tree expands that far. Combine that with copycat attacks, where one person does one thing and others feel motivated to push their button, it exasperates the problem.

A perfect example is webpack. Indirectly depends on many thousands of different packages, is run during development, and has 225k packages that depend upon it. https://github.com/webpack/webpack/network/dependencies i.e. even if you are careful about dependencies, your build tools are not.

I also checked esbuild which is written in go, but it still has a dependency on babel and webpack (via scripts/package.json fuse.js at least). https://github.com/evanw/esbuild/network/dependencies

esbuild doesn't depend on babel or webpack if you're just using esbuild (maybe it does if you want to build esbuild from source?) My pet project uses esbuild and the relevant part of the dependency tree only shows 'esbuild@0.14.27' which depends on 'esbuild-linux-64@0.14.27' (which is the binary package) - it doesn't extend any further than that.

Go at least will never run arbitrary package code as part of a go get / go build / go install.

Only the resulting binary might contain malicious code, but the build and package management part is guaranteed safe.

In addition, go installs the oldest viable version that matches constraints - dependencies are thus not only locked, but also don’t automatically update to the newest available version during relocking unless explicitly requested by the user or another dependency.

> In theory the same things could happen for PIP, Maven, Gradle, their Rust and Go counterpart and any such package manager. Any data on this?

Rust employs version locking for it's builds, so you'll only be able to propagate malware with it if:

0. The developer's cargo definition auto-grabs the latest dependencies (trust me, very few do this)

1. The developer has deliberately updated the version of their dependency

2. The developer doesn't notice any significant changes when debugging/staging the new release

3. The package passed through testing without identifying any malware or malicious changes

In theory, it's possible to distribute malware with Rust's dependency system, but doing so would be pretty difficult. I'd say there's some pretty good roadblocks in place to prevent it from happening.

The only real change from the NPM case is speed of distribution of the end results, users don't need to consciously update. NPM has package and package-lock just like there is cargo and cargo-lock, so devs are just as in control of the dependency versions they are shipping.

> Maven, Gradle

It's very uncommon to specify the "latest" version in Java package managers. The capability is there, but everyone always specifies something exact. And there aren't nearly as many transitive dependencies. Many popular Java libraries don't have any dependencies at all. And, at least on Maven Central, you can't overwrite an already released version of a package, you can only add a new one.

Reply on news.ycombinator.com