7 ms·

“No way to prevent this” says only package manager where this regularly happens.

by nepthar 4mo ago

bakugo 4mo ago
Is there anything about npm that makes it particularly susceptible to these attacks, other than the fact that it's the most popular package manager of all?
- freakynit 4mo ago
  Yep. 1. Every day there's a new package. 2. Then five more packages appear so you don't have to write that one terrifying line of JavaScript yourself. 3. Then someone writes a wrapper around those five packages. 4. Then someone writes a "modern, lightweight, zero-config" wrapper around the wrapper. 5. Then a framework adopts it, a build tool requires it, and suddenly your todo app has a dependency graph that looks like international diplomacy. 6. Out of 100 devs building the same product, there are now 300 different dependency combinations, all somehow involving 'left-pad' spiritually if not literally. 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues. 8. The other half were abandoned three years ago but still have 40 million weekly downloads because removing them would break civilization. 9. Pinning dependencies sounds nice until the ecosystem tells you, "sorry, this package only works with Node 22, this plugin needs Node 18, and this transitive dependency has discovered ESM enlightenment." 10. So everyone lives on the bleeding edge, except nobody agrees where the edge is, and the bleeding part is very real. So yeah, npm is not uniquely cursed because JavaScript devs are worse. It's cursed because it turned code reuse into a lifestyle, dependency trees into rainforests, and 'npm install' into an act of faith.
  - MadnessASAP 4mo ago
    > 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues. By a manager for for a >$1 billion market cap corporation who doesnt understand that the one person isnt an employee.
  - Hammershaft 4mo ago
    Pangram says this comment is %100 LLM generated. It certainly reads as LLM generated!
    - freakynit 4mo ago
      It was.. but not in the way people generally think. Im not a native english speaker. Therefore, I use chatgpt to fix my comment sometimes. This was done the same way.
      - pattilupone 4mo ago
        I get it and I'm not trying to get down on you, but I've seen people around say this and it bugs me. I don't know Japanese at all. Sometimes I use LLMs to translate discord messages into Japanese so I can communicate with Japanese people. Then as verification I translate the messages back (with different LLMs) and they usually come out as a near-verbatim version of what I wanted to say. In other words, they don't come out in the chatgpt style of writing. If I'm able to do that, then chatgpt should be able to fix your English without chatgpt-ifying the whole comment.
        freakynit 4mo ago
        Point accepted. But, If there are people who focus more on chatgpt "style" of writing, rather than what the message is conveying, frankly, I don't care. These things are here, they are here to say, and expand into a lot more domains.
- kommunicate 4mo ago
  npm can execute code after install and most package managers don't do that
  - joshkel 4mo ago
    I'm far from an expert, but this feels like an oversimplification. Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control. Native Ruby Gems execute arbitrary code via extconf.rb. Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorporated into your build (and so can run code at build time). PHP Composer packages can ship install scripts or configure themselves as Composer plugins. The venerable .tar.gz approach to packaging, covering decades of C and C++ code, is all about executing code during installation. There are measures that can help (e.g., PHP Composer doesn't run install scripts of _transitive_ dependencies) but the JS space is adopting measures that can help too (like pnpm's approve-builds).
    - amiga386 4mo ago
      > Python packages traditionally use setup.py But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. > PHP Composer packages can ship install scripts Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "composer -n config allow-plugins.foo/bar true && composer -n require foo/bar" > The venerable .tar.gz approach to packaging Which most people don't install directly, but have already had built for them by their distro. As more and more languages get "package managers", there's an expectation that installing what should just be inert package/library code should not run commands. Sometimes generated files are needed, and the direction seems to be that these package managers should be like distro package managers, where they take the risk of running the build instructions and generate those files for you, serving up os/architecture-specific builds. This is the direction npm ought to take, and furthermore shouldn't allow things like electron being a small bundle of javascript code that fetches large lumps of binary code from somewhere else on the internet to install. It should all be uploaded to, and sourced from, NPM.
- Sohcahtoa82 4mo ago
  It's the general ecosystem. There's not a word in the English language that really expresses how absolutely stupid the npm ecosystem is and the developers that perpetuate it by importing a package rather than writing 5 lines of code.
- staticassertion 4mo ago
  No. NPM's not particularly bad at all tbh.
downrightmike 4mo ago
OWNED BY MICROSOFT

“No way to prevent this” says only package manager where this regularly happens.

by nepthar 4mo ago

“No way to prevent this” says only package manager where this regularly happens.

Is there anything about npm that makes it particularly susceptible to these attacks, other than the fact that it's the most popular package manager of all?

freakynit 4mo ago
Yep. 1. Every day there's a new package. 2. Then five more packages appear so you don't have to write that one terrifying line of JavaScript yourself. 3. Then someone writes a wrapper around those five packages. 4. Then someone writes a "modern, lightweight, zero-config" wrapper around the wrapper. 5. Then a framework adopts it, a build tool requires it, and suddenly your todo app has a dependency graph that looks like international diplomacy. 6. Out of 100 devs building the same product, there are now 300 different dependency combinations, all somehow involving 'left-pad' spiritually if not literally. 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues. 8. The other half were abandoned three years ago but still have 40 million weekly downloads because removing them would break civilization. 9. Pinning dependencies sounds nice until the ecosystem tells you, "sorry, this package only works with Node 22, this plugin needs Node 18, and this transitive dependency has discovered ESM enlightenment." 10. So everyone lives on the bleeding edge, except nobody agrees where the edge is, and the bleeding part is very real. So yeah, npm is not uniquely cursed because JavaScript devs are worse. It's cursed because it turned code reuse into a lifestyle, dependency trees into rainforests, and 'npm install' into an act of faith.
- MadnessASAP 4mo ago
  > 7. Half the packages are maintained by one person, unpaid, at 2 a.m., after getting yelled at in GitHub issues. By a manager for for a >$1 billion market cap corporation who doesnt understand that the one person isnt an employee.
- Hammershaft 4mo ago
  Pangram says this comment is %100 LLM generated. It certainly reads as LLM generated!
  - freakynit 4mo ago
    It was.. but not in the way people generally think. Im not a native english speaker. Therefore, I use chatgpt to fix my comment sometimes. This was done the same way.
    - pattilupone 4mo ago
      I get it and I'm not trying to get down on you, but I've seen people around say this and it bugs me. I don't know Japanese at all. Sometimes I use LLMs to translate discord messages into Japanese so I can communicate with Japanese people. Then as verification I translate the messages back (with different LLMs) and they usually come out as a near-verbatim version of what I wanted to say. In other words, they don't come out in the chatgpt style of writing. If I'm able to do that, then chatgpt should be able to fix your English without chatgpt-ifying the whole comment.
      - freakynit 4mo ago
        Point accepted. But, If there are people who focus more on chatgpt "style" of writing, rather than what the message is conveying, frankly, I don't care. These things are here, they are here to say, and expand into a lot more domains.
kommunicate 4mo ago
npm can execute code after install and most package managers don't do that
- joshkel 4mo ago
  I'm far from an expert, but this feels like an oversimplification. Python packages traditionally use setup.py to install code, and setup.py is all executable code under the installed package's control. Native Ruby Gems execute arbitrary code via extconf.rb. Pre .NET Core, NuGet packages could ship scripts like `install.ps1`. That's been removed, but they can still ship `.targets` and `.props` files that are incorporated into your build (and so can run code at build time). PHP Composer packages can ship install scripts or configure themselves as Composer plugins. The venerable .tar.gz approach to packaging, covering decades of C and C++ code, is all about executing code during installation. There are measures that can help (e.g., PHP Composer doesn't run install scripts of _transitive_ dependencies) but the JS space is adopting measures that can help too (like pnpm's approve-builds).
  - amiga386 4mo ago
    > Python packages traditionally use setup.py But nowadays prefer pyproject.toml, and most people use pre-built distributions (wheels) for their architecture from PyPI, so don't execute arbitrary code to install packages. > PHP Composer packages can ship install scripts Which requires the user to say yes to running them, but they can also say they only want a specific package to run scripts with something like "composer -n config allow-plugins.foo/bar true && composer -n require foo/bar" > The venerable .tar.gz approach to packaging Which most people don't install directly, but have already had built for them by their distro. As more and more languages get "package managers", there's an expectation that installing what should just be inert package/library code should not run commands. Sometimes generated files are needed, and the direction seems to be that these package managers should be like distro package managers, where they take the risk of running the build instructions and generate those files for you, serving up os/architecture-specific builds. This is the direction npm ought to take, and furthermore shouldn't allow things like electron being a small bundle of javascript code that fetches large lumps of binary code from somewhere else on the internet to install. It should all be uploaded to, and sourced from, NPM.
Sohcahtoa82 4mo ago
It's the general ecosystem. There's not a word in the English language that really expresses how absolutely stupid the npm ecosystem is and the developers that perpetuate it by importing a package rather than writing 5 lines of code.
staticassertion 4mo ago
No. NPM's not particularly bad at all tbh.

downrightmike 4mo ago

OWNED BY MICROSOFT