Remix.run Logo
wiradikusuma 5 hours ago

Does anyone know why NPM seems to be the only attractive target? Python and Java are very popular, but I haven't heard anything in those ecosystems for a while. Is it because something inherently "weak" about NPM, or simply because, like Windows or JavaScript, everyone uses it?

broeng an hour ago | parent | next [-]

Compared to the Java ecosystem, I think there's a couple of issues in the NPM ecosystem that makes the situation a lot worse:

1) The availability of the package post-install hook that can run any command after simply resolving and downloading a package[1].

That, combined with:

2) The culture with using version ranges for dependency resolution[2] means that any compromised package can just spread with ridiculous speed (and then use the post-install hook to compromise other packages). You also have version ranges in the Java ecosystem, but it's not the norm to use in my experience, you get new dependencies when you actively bump the dependencies you are directly using because everything depends on specific versions.

I'm no NPM expert, but that's the worst offenders from a technical perspective, in my opinion.

[1]: I'm sure it can be disabled, and it might even be now by default - I don't know. [2]: Yes, I know you can use a lock file, but it's definitely not the norm to actively consider each upgraded version when refreshing the lockfile.

kace91 3 hours ago | parent | prev | next [-]

One factor is that node's philosophy is to have a very limited standard library and rely on community software for a ton of stuff.

That means that not only the average project has a ton of dependencies, but also any given dependency will in turn have a ton of dependencies as well. there’s multiplicative effects in play.

louiskottmann 2 hours ago | parent | next [-]

This is my take as well. I've never come accross a JS project where the built-in datastructures were exclusively used.

One package for lists, one for sorting, and down the rabbit hole you go.

rhubarbtree 2 hours ago | parent | prev [-]

This is the main reason. Pythons ecosystem also has silly trends and package churn, and plenty of untrained developers. It’s the lack of a proper standard library. As bad a language as it may be, Java shows how to get this right.

palata 2 hours ago | parent | next [-]

> As bad a language as it may be, Java shows how to get this right.

To be fair Java has improved a lot over the last few years. I really have the feeling that Java is getting better, while C++ is getting worse.

PhilipRoman 10 minutes ago | parent | prev [-]

What? Python's standard library seems far more extensive than Java's.

parliament32 5 hours ago | parent | prev | next [-]

Larger attack surface (JS has been the #1 language on GitHub for years now) and more amateur developers (who are more likely to blindly install dependencies, not harden against dev attack vectors, etc).

Sophira 3 hours ago | parent | next [-]

Unfortunately, blindly installing dependencies at compile-time is something that many projects will do by default nowadays. It's not just "more amateur developers" who are at risk here.

I've even seen "setup scripts" for projects that will use root (with your permission) to install software. Such scripts are less common now with containers, but unfortunately containers aren't everything.

dboreham 4 hours ago | parent | prev [-]

Also: a culture of constant churn in libraries which in combination with the potential for security bugs to be fixed in any new release leads to a common practice of ingesting a continual stream of mystery meat. That makes filtering out malware very hard. Too much noise to see the signal. None of the above cultural factors is present in the other ecosystems.

nottorp 19 minutes ago | parent | prev | next [-]

Maybe some technical reasons, but more like the mind set of the JS "community" that if you don't have the latest version of a package 30 seconds after it's pushed you're hopelessly behind.

In other "communities" you upgrade dependencies when you have time to evaluate the impact.

Balinares 2 hours ago | parent | prev | next [-]

As far as I understand, NPM packages are not self-contained like e.g. Python wheels and can (and often need to) run scripts on install.

So just installing a package can get you compromised. If the compromised box contains credentials to update your own packages in NPM, then it's an easy vector for a worm to propagate.

magnetometer 24 minutes ago | parent [-]

Python wheels don't run arbitrary code on install, but source distributions do. And you can upload both to pypy. So you would have to run

pip install <package> --only-binary :all:

to only install wheels and fail otherwise.

dtech 4 hours ago | parent | prev | next [-]

Npm has weak security boundaries.

Basically any dependency can (used to?) run any script with the develop permissions on install. JVM and python package managers don't do this.

Of course in all ecosystems once you actually run the code it can do whatever with the permissions of the executes program, but this is another hurdle.

lights0123 3 hours ago | parent [-]

Python absolutely can run scripts in installation. Before pyproject.toml, arbitrary scripts were the only way to install a package. It's the reason PyPi.org doesn't show a dependency graph, as dependencies are declared in the Turing-complete setup.py.

oefrha 3 hours ago | parent [-]

Wrong. Wheels were available long before pyproject.toml, and you could instruct pip to only install from wheels. setup.py was needed to build the wheels, but the build step wasn’t a necessary part of installation and could be disabled. In that sense its role is similar to that of pre-publish build step of npm packages, unless wheels aren’t available.

Ekaros 2 hours ago | parent | prev [-]

I feel with Python upgrade cycle is slower. I upgrade dependencies when something is broken or there is known issue. That means any active vulnerabilities propagate slower. Slower propagation means lower risk. And also as there is fewer upstream packages impact of compromised maintainer is more limited.