3 ms·

Mitigate it with: echo "ignore-scripts=true" >> ~/.npmrc https://blog.uxtly.com/getting-rid-of-npm-scripts https://blog.uxtly.com/getting-rid-of-npm-scripts

wrs 1y ago
Some packages have install scripts that actually need to run (e.g., esbuild). pnpm refuses to run install scripts from packages you haven’t manually authorized, which helps a bit.
- efortis 1y ago
  Yes, at the end of that blog there are two options for that: npm install --ignore-scripts=false package-i-trust Or, trigger the installation script: node node_modules/puppeteer/install.js
  - wrs 1y ago
    The pnpm version of this is persistent. You approve the package once, and regular install works thereafter. Which is nice.
    - DemocracyFTW2 1y ago
      is that permission tied to a specific version with a specific fingerprint/hash? because if it's not then you could still get a surprise come the next update...
      - wrs 1y ago
        It is by package name, but at least you won't be surprised when left-pad suddenly has an install script. You can put a fingerprint on the package dependency itself, though, so if you add a fingerprint to anything you approve the install script for, you will get that level of safety.
- lrvick 1y ago
  pnpm cannot be built from source without an existing pnpm binary making it ineligible for inclusion in any reproducible Linux distro, for good reason, as there is no way to rule out a trusting trust attack. Pnpm should be considered for hobby use cases only.
lrvick 1y ago
And then the vulnerable code will just move to shell execs in the main library that fire the next time you include the library in your project. If you do not have time to review a library, then do not use it.
- singulasar 1y ago
  I'm so sick of people saying this. If you use js for any non-tiny project, you'll have a bunch of packages. Due to how modules work in js, you'll have many, many sub dependencies. Nobody has time to review every package they'll use, especially when not all sub dependencies have fully pinned versions. If you have time to review every package, every time it updates, you might as well just write it yourself. Yes, this is a problem, no reviewing every dependency is not the damn solution
  - efortis 1y ago
    Show them this Ken Thompson paper of 1984: "Reflections on Trusting Trust" https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... And then hardware compromises… I don't mean install anything. I mean, it's not a problem particular to the JS ecosystem.
    - lrvick 1y ago
      I full source bootstrapped a Linux distro from hex0 all the way to nodejs binaries just to deal with trusting trust risks. "just give up" is not a valid strategy. https://codeberg.org/stagex/stagex https://codeberg.org/stagex/stagex
      - efortis 1y ago
        where can I follow you? blog, x?
        lrvick 1y ago

wrs 1y ago

Some packages have install scripts that actually need to run (e.g., esbuild). pnpm refuses to run install scripts from packages you haven’t manually authorized, which helps a bit.

efortis 1y ago
Yes, at the end of that blog there are two options for that: npm install --ignore-scripts=false package-i-trust Or, trigger the installation script: node node_modules/puppeteer/install.js
- wrs 1y ago
  The pnpm version of this is persistent. You approve the package once, and regular install works thereafter. Which is nice.
  - DemocracyFTW2 1y ago
    is that permission tied to a specific version with a specific fingerprint/hash? because if it's not then you could still get a surprise come the next update...
    - wrs 1y ago
      It is by package name, but at least you won't be surprised when left-pad suddenly has an install script. You can put a fingerprint on the package dependency itself, though, so if you add a fingerprint to anything you approve the install script for, you will get that level of safety.
lrvick 1y ago
pnpm cannot be built from source without an existing pnpm binary making it ineligible for inclusion in any reproducible Linux distro, for good reason, as there is no way to rule out a trusting trust attack. Pnpm should be considered for hobby use cases only.

lrvick 1y ago

And then the vulnerable code will just move to shell execs in the main library that fire the next time you include the library in your project. If you do not have time to review a library, then do not use it.

singulasar 1y ago
I'm so sick of people saying this. If you use js for any non-tiny project, you'll have a bunch of packages. Due to how modules work in js, you'll have many, many sub dependencies. Nobody has time to review every package they'll use, especially when not all sub dependencies have fully pinned versions. If you have time to review every package, every time it updates, you might as well just write it yourself. Yes, this is a problem, no reviewing every dependency is not the damn solution
- efortis 1y ago
  Show them this Ken Thompson paper of 1984: "Reflections on Trusting Trust" https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref... And then hardware compromises… I don't mean install anything. I mean, it's not a problem particular to the JS ecosystem.
  - lrvick 1y ago
    I full source bootstrapped a Linux distro from hex0 all the way to nodejs binaries just to deal with trusting trust risks. "just give up" is not a valid strategy. https://codeberg.org/stagex/stagex https://codeberg.org/stagex/stagex
    - efortis 1y ago
      where can I follow you? blog, x?
      - lrvick 1y ago