3 ms·

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

by aulin 5y ago

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

extheat 5y ago
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.
robocat 5y ago
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 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 https://github.com/evanw/esbuild/network/dependencies
- azornathogron 5y ago
  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.

by aulin 5y ago

extheat 5y ago

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.

robocat 5y ago

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 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 https://github.com/evanw/esbuild/network/dependencies

azornathogron 5y ago
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.