3 ms·

It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencie

It's crazy to me that npm still executes postinstall scripts by default for all dependencies. Other package managers (Pnpm, Bun) do not run them for dependencies unless they are added to a specific allow-list. Composer never runs lifecycle scripts for dependencies. This matters because dependencies are often installed in a build or development environment with access to things that are not available when the package is actually imported in a browser or other production environment.

notatallshaw 1y ago
Seems like this is a fairly recent change, for Pnpm at least, https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts-by-default https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts... What has been the community reaction? Has allowing scripts been scalable for users? Or could it be described as people blindly copying and pasting allow commands? I am involved in Python packaging discussions and there is a pre-proposal (not at PEP stage yet) at the moment for "wheel variants" that involves a plugin architecture, a contentious point is whether to download and run the plugins by default. I'd like to find parallels in other language communities to learn from.
- theodorejb 1y ago
  In my experience, packages which legitimately require a postinstall script to work correctly are very rare. For the apps I maintain, esbuild is the only dependency which benefits from a postinstall script to slightly improve performance (though it still works without the script). So there's no scaling issue adding one or two packages to a whitelist if desired.
LelouBil 1y ago
I'm also wondering why huge scale attacks like this don't happen for other package managers. Like, for rust, you can have a build.rs file that gets executed when your crate is compiled, I don't think it's sandboxed. Or also on other languages that will get run on development machines, like python packages (which can trigger code only on import), java libraries, etc... Like, there is the post install script issue or course, but I feel like these attacks could have been just as (or almost as) effective in other programming languages, but I feel like we always only hear about npm packages.
- Onavo 1y ago
  It's a lot harder to do useful things with backend languages. JavaScript is more profitable as you can do the crypto wallet attacks without having to exploit kernel zero days.
  - 0x000xca0xfe 1y ago
    It's trivial to run an exploit shell from almost any language when you have non-sandboxed code running on the target machine.
    - Onavo 1y ago
      Yes but outside of dumping user data, there's not much else you can do. Crypto mining will get caught rather quickly (most big clouds ban mining). User data is useful for the type of attacker that's willing to go through the whole blackmarketing selling process. For script kiddies, if you think about it, the easiest pay-off for a social engineering/phishing is a frontend wallet crypto theft.
      - 0x000xca0xfe 1y ago
        This has still nothing to do with the language or kernel exploits. Only code execution on a valuable host matters. You could make a malicious Rust crate that on installation runs a Python shell and injects JavaScript into your browser to extract crypto wallets. There even seems to be a significant overlap of Rust devs/crypto fans. Also script kiddies don't do social engineering and blackmarket crypto selling, that's 100% professional crime territory. Real-life script kiddie attacks I've seen were more like hacking an ecommerce site and adding bananas as currency.
- voxelghost 1y ago
  Its only JS devs that constantly rebuild their system with full dependcy update, so they are the most attractive target.
- silverwind 1y ago
VPenkov 1y ago
It does not, since version 11: https://docs.npmjs.com/cli/v11/using-npm/changelog#1100-pre0-2024-11-26 https://docs.npmjs.com/cli/v11/using-npm/changelog#1100-pre0...
- theodorejb 1y ago
  Yes it does, since the ignore-scripts option is not enabled by default.
  - VPenkov 1y ago
    Yes it does, you're correct and I have misread. I can't edit, delete, or flag my initial reply unfortunately.

notatallshaw 1y ago

Seems like this is a fairly recent change, for Pnpm at least, https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts-by-default https://socket.dev/blog/pnpm-10-0-0-blocks-lifecycle-scripts... What has been the community reaction? Has allowing scripts been scalable for users? Or could it be described as people blindly copying and pasting allow commands? I am involved in Python packaging discussions and there is a pre-proposal (not at PEP stage yet) at the moment for "wheel variants" that involves a plugin architecture, a contentious point is whether to download and run the plugins by default. I'd like to find parallels in other language communities to learn from.

theodorejb 1y ago
In my experience, packages which legitimately require a postinstall script to work correctly are very rare. For the apps I maintain, esbuild is the only dependency which benefits from a postinstall script to slightly improve performance (though it still works without the script). So there's no scaling issue adding one or two packages to a whitelist if desired.

LelouBil 1y ago

I'm also wondering why huge scale attacks like this don't happen for other package managers. Like, for rust, you can have a build.rs file that gets executed when your crate is compiled, I don't think it's sandboxed. Or also on other languages that will get run on development machines, like python packages (which can trigger code only on import), java libraries, etc... Like, there is the post install script issue or course, but I feel like these attacks could have been just as (or almost as) effective in other programming languages, but I feel like we always only hear about npm packages.

Onavo 1y ago
It's a lot harder to do useful things with backend languages. JavaScript is more profitable as you can do the crypto wallet attacks without having to exploit kernel zero days.
- 0x000xca0xfe 1y ago
  It's trivial to run an exploit shell from almost any language when you have non-sandboxed code running on the target machine.
  - Onavo 1y ago
    Yes but outside of dumping user data, there's not much else you can do. Crypto mining will get caught rather quickly (most big clouds ban mining). User data is useful for the type of attacker that's willing to go through the whole blackmarketing selling process. For script kiddies, if you think about it, the easiest pay-off for a social engineering/phishing is a frontend wallet crypto theft.
    - 0x000xca0xfe 1y ago
      This has still nothing to do with the language or kernel exploits. Only code execution on a valuable host matters. You could make a malicious Rust crate that on installation runs a Python shell and injects JavaScript into your browser to extract crypto wallets. There even seems to be a significant overlap of Rust devs/crypto fans. Also script kiddies don't do social engineering and blackmarket crypto selling, that's 100% professional crime territory. Real-life script kiddie attacks I've seen were more like hacking an ecommerce site and adding bananas as currency.
voxelghost 1y ago
Its only JS devs that constantly rebuild their system with full dependcy update, so they are the most attractive target.
silverwind 1y ago

VPenkov 1y ago

It does not, since version 11: https://docs.npmjs.com/cli/v11/using-npm/changelog#1100-pre0-2024-11-26 https://docs.npmjs.com/cli/v11/using-npm/changelog#1100-pre0...

theodorejb 1y ago
Yes it does, since the ignore-scripts option is not enabled by default.
- VPenkov 1y ago
  Yes it does, you're correct and I have misread. I can't edit, delete, or flag my initial reply unfortunately.