4 ms·

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.

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?

parliament32 11mo ago
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).
- dboreham 11mo ago
  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.
- Sophira 11mo ago
  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.
  - 1718627440 11mo ago
    > blindly installing dependencies at compile-time is something that many projects will do by default nowadays. I consider this to be a sign that someone is still an amateur, and this is a reason to not use the software and quickly delete it. If you need a dependency, you can call the OS package manager, or tell me to compile it myself. If you start a network connection, you are malware in my eyes.
  - Cthulhu_ 11mo ago
    Yes, exactly; I followed a Github course at one point and it was Strongly Recommended that you enable Dependabot for your project which will keep your dependencies up to date. It's basically either already enabled or a one-click setup action at this point. The norm that Github pushes is that you should trust them to keep your stuff updated and secure.
dtech 11mo ago
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 11mo ago
  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 11mo ago
    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.
- silverwind 11mo ago
  Deno has tackled some of these issues with their permission system, but afaik it can only be applied to apps, not to dependencies. What we really need is a system to restrict packages in what they can do (for example, many packages don't need network access).
  - duncanbeevers 11mo ago
    Lavamoat purports to do this. https://lavamoat.github.io/ https://lavamoat.github.io/ There has been some promising prior research such as BreakApp attempting to mitigate unusual supply-chain compromises such as denial-of-service attacks targeting the CPU via pathological regexps or other logic-bomb-flavored payloads.
torben-friis 11mo ago
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.
- rhubarbtree 11mo ago
  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 11mo ago
    > 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 11mo ago
    What? Python's standard library seems far more extensive than Java's.
    - yunwal 11mo ago
      Yeah if anything I'm used to the opposite complaint about python that there's too much included in the stdlib.
    - rhubarbtree 11mo ago
      A strange typo: should have written “node”. Kinda changed the intent of my comment. Oops.
  - rhubarbtree 11mo ago
    Goddamnit: meant to write “node’s” not “pythons”. Human is hallucinating.
Ekaros 11mo ago
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.
Balinares 11mo ago
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 11mo ago
  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.
  - Balinares 11mo ago
    Fair point -- I was only thinking wheels, but you are right. Would source distributions work as a vector for automated propagation, though? If I'm not mistaken, there's no universal standard for building from source distributions.
broeng 11mo ago
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.
- Cthulhu_ 11mo ago
  To add a few: * NPM has a culture of "many small dependencies", so there's a very long tail of small projects that are mostly below the radar that wouldn't stand out initially if they get a patch update. People don't look critically into updated versions because there's so many of them. * Developers have developed a culture of staying up-to-date as much as possible, so any patch release is applied as soon as possible, often automated. This is mainly sold as a security feature, so that a vulnerability gets patched and released before disclosure is done. But it was (is?) also a thing where if you wait too long to update, updating takes more time and effort because things keep breaking.
- silverwind 11mo ago
  > The culture with using version ranges for dependency resolution Yep, auto-updating dependencies are the main culprit why malware can spread so fast. I strongly recommend the use `save-exact` in npm and only update your dependencies when you actually need to.
  - tedivm 11mo ago
    This advice leaves you vulnerable to log4j style vulnerabilities that get discovered though. The answer is a balance. Use Dependabot to keep dependencies up to date, but configure a dependency cooldown so you don't end up installing anything too new. A seven day cooldown would keep you from being vulnerable to these types of attacks.
nottorp 11mo ago
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.
Karliss 11mo ago
For the last 2 years PyPi (main Python package repository) requires mandatory 2FA. Last time I did anything with Java, felt like use of multiple package repositories including private ones was a lot more popular. Although higher branching factor for JavaScript and potential target count are probably very important factors as well.
DANmode 11mo ago
As it turns out, vibe coding started with npm, not chat bots.
sgammon 11mo ago
NPM lets you upload literally anything, without approval

parliament32 11mo ago

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

dboreham 11mo ago
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.
Sophira 11mo ago
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.
- 1718627440 11mo ago
  > blindly installing dependencies at compile-time is something that many projects will do by default nowadays. I consider this to be a sign that someone is still an amateur, and this is a reason to not use the software and quickly delete it. If you need a dependency, you can call the OS package manager, or tell me to compile it myself. If you start a network connection, you are malware in my eyes.
- Cthulhu_ 11mo ago
  Yes, exactly; I followed a Github course at one point and it was Strongly Recommended that you enable Dependabot for your project which will keep your dependencies up to date. It's basically either already enabled or a one-click setup action at this point. The norm that Github pushes is that you should trust them to keep your stuff updated and secure.

dtech 11mo ago

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 11mo ago
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 11mo ago
  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.
silverwind 11mo ago
Deno has tackled some of these issues with their permission system, but afaik it can only be applied to apps, not to dependencies. What we really need is a system to restrict packages in what they can do (for example, many packages don't need network access).
- duncanbeevers 11mo ago
  Lavamoat purports to do this. https://lavamoat.github.io/ https://lavamoat.github.io/ There has been some promising prior research such as BreakApp attempting to mitigate unusual supply-chain compromises such as denial-of-service attacks targeting the CPU via pathological regexps or other logic-bomb-flavored payloads.

torben-friis 11mo ago

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.

rhubarbtree 11mo ago
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 11mo ago
  > 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 11mo ago
  What? Python's standard library seems far more extensive than Java's.
  - yunwal 11mo ago
    Yeah if anything I'm used to the opposite complaint about python that there's too much included in the stdlib.
  - rhubarbtree 11mo ago
    A strange typo: should have written “node”. Kinda changed the intent of my comment. Oops.
- rhubarbtree 11mo ago
  Goddamnit: meant to write “node’s” not “pythons”. Human is hallucinating.

Ekaros 11mo ago

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.

Balinares 11mo ago

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 11mo ago
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.
- Balinares 11mo ago
  Fair point -- I was only thinking wheels, but you are right. Would source distributions work as a vector for automated propagation, though? If I'm not mistaken, there's no universal standard for building from source distributions.

broeng 11mo ago

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.

Cthulhu_ 11mo ago
To add a few: * NPM has a culture of "many small dependencies", so there's a very long tail of small projects that are mostly below the radar that wouldn't stand out initially if they get a patch update. People don't look critically into updated versions because there's so many of them. * Developers have developed a culture of staying up-to-date as much as possible, so any patch release is applied as soon as possible, often automated. This is mainly sold as a security feature, so that a vulnerability gets patched and released before disclosure is done. But it was (is?) also a thing where if you wait too long to update, updating takes more time and effort because things keep breaking.
silverwind 11mo ago
> The culture with using version ranges for dependency resolution Yep, auto-updating dependencies are the main culprit why malware can spread so fast. I strongly recommend the use `save-exact` in npm and only update your dependencies when you actually need to.
- tedivm 11mo ago
  This advice leaves you vulnerable to log4j style vulnerabilities that get discovered though. The answer is a balance. Use Dependabot to keep dependencies up to date, but configure a dependency cooldown so you don't end up installing anything too new. A seven day cooldown would keep you from being vulnerable to these types of attacks.

nottorp 11mo ago

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.

Karliss 11mo ago

For the last 2 years PyPi (main Python package repository) requires mandatory 2FA. Last time I did anything with Java, felt like use of multiple package repositories including private ones was a lot more popular. Although higher branching factor for JavaScript and potential target count are probably very important factors as well.

DANmode 11mo ago

As it turns out, vibe coding started with npm, not chat bots.

sgammon 11mo ago

NPM lets you upload literally anything, without approval