5 ms·

postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run ran

by atraac 4mo ago

postinstall scripts should've been removed long time ago, it's the cancer of NPM packages. There's so many deeply nested, uncontrolled postinstalls that run randomly when you pull something it's insane, I don't know how someone at some point ever though that was a good idea.

gear54rus 4mo ago
Absolutely not, there are plenty of use-cases for them. https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package comes to mind off the top of my head. Hopefully current hysteria will not result in some bs decisions like this.
- philipwhiuk 4mo ago
  The entire use-case of that package is a security nightmare.
  - gear54rus 4mo ago
    Then don't use it. Just don't presume to tell me if I can or can't.
    - dgellow 4mo ago
      Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself
      - gear54rus 4mo ago
        [flagged]
        ramon156 4mo ago
        Elaborate on the "behave properly". What is properly here?
        prophesi 4mo ago
        Or maybe just add a script in package.json to run whatever patch-package does (eg, "install:patch": "npm install && patch-package") instead of whitelisting every package to have that power.
    - port11 4mo ago
      You’re free to allow scripts as per the linked docs for NPM 12. But the vast majority of us will appreciate the reduced attack surface.
    - jeremyjh 4mo ago
      TFA explains how this works, and how to opt out.
- homebrewer 4mo ago
  Your own link says that a proper package manager (e.g. pnpm) supports this out of the box. If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages). You enable just one or two of those, and block everything else.
- atraac 4mo ago
  How would getting rid of postinstall break patch-package? If people use a package, and that package needs some kind of step to get working, user of that package should decide when that step happens. He can very well just call patch before building on his own. There's zero issues with that approach and the upside is he actually has control. I work in a monorepo where running install calls dozens of deeply nested postinstalls of some elaborate NextJs or React Native dependencies other projects use. It's borderline insane. Unless you regularly screen everything, it's impossible to know whether one of those is compromised, especially in the world of Node where is-even is being used and the sheer amount of crypto scams around.
VMG 4mo ago
I must admit I don't really understand what the point of the post-install script concern is. Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process. So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens. It seems to me that this is a small stumbling block at best, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?
- vbezhenar 4mo ago
  You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE). I didn't try devcontainers stuff, TBH. But that's how I often develop my apps. That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.
  - rafaelmn 4mo ago
    >You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE). At this point I will not do any dev outside of a container - so many things can be supply chained in the OSS dev stack it's just not worth it, and once you get used to developing in containers it's actually a lot cleaner to move between hosts - you're essentially treating your client as a remote terminal. If you're doing web dev work in this day an age SSH with tmux or some editor with SSH server support should be your dev setup.
- jeremyjh 4mo ago
  A lot of packages are only used in the browser; if you don't use SSR they'd only be executed by node in unit tests in something like jest, but that is not the only way to run unit tests (Cypress can run them in a headless browser [1], for example). Running those sand-boxed would be the next logical step. Removing automated execution of postinstall is a necessary step and may as well be the first one. [1] https://docs.cypress.io/app/component-testing/get-started?utm_source=chatgpt.com https://docs.cypress.io/app/component-testing/get-started?ut...
hinkley 4mo ago
On a project with a 1GB node_modules directory (after aggressive cleanup) I think we only had one dependency that didn't work right with postinstall disabled. Though I can't recall which and I don't work there anymore so I can't hunt. And IIRC that one was fixable by a PR, because they'd done something weird and there was an idiomatic way to accomplish the same thing.

by atraac 4mo ago

gear54rus 4mo ago

Absolutely not, there are plenty of use-cases for them. https://www.npmjs.com/package/patch-package https://www.npmjs.com/package/patch-package comes to mind off the top of my head. Hopefully current hysteria will not result in some bs decisions like this.

philipwhiuk 4mo ago
The entire use-case of that package is a security nightmare.
- gear54rus 4mo ago
  Then don't use it. Just don't presume to tell me if I can or can't.
  - dgellow 4mo ago
    Given that has an impact over the whole industry, I will for sure tell you that patching on install SHOULD NOT be a thing. Up to you to run your own post install script yourself
    - gear54rus 4mo ago
      [flagged]
      - ramon156 4mo ago
        Elaborate on the "behave properly". What is properly here?
      - prophesi 4mo ago
        Or maybe just add a script in package.json to run whatever patch-package does (eg, "install:patch": "npm install && patch-package") instead of whitelisting every package to have that power.
  - port11 4mo ago
    You’re free to allow scripts as per the linked docs for NPM 12. But the vast majority of us will appreciate the reduced attack surface.
  - jeremyjh 4mo ago
    TFA explains how this works, and how to opt out.
homebrewer 4mo ago
Your own link says that a proper package manager (e.g. pnpm) supports this out of the box. If there are other use cases that really need post-install scripts, you can whitelist just those in pnpm. In projects I'm working with, there are often zero post-install scripts that must be enabled for everything to work properly, and it's usually from poorly cobbled packages that use them to download prebuilt binaries (well written packages, like biome or tsgo, use per-architecture subpackages). You enable just one or two of those, and block everything else.
atraac 4mo ago
How would getting rid of postinstall break patch-package? If people use a package, and that package needs some kind of step to get working, user of that package should decide when that step happens. He can very well just call patch before building on his own. There's zero issues with that approach and the upside is he actually has control. I work in a monorepo where running install calls dozens of deeply nested postinstalls of some elaborate NextJs or React Native dependencies other projects use. It's borderline insane. Unless you regularly screen everything, it's impossible to know whether one of those is compromised, especially in the world of Node where is-even is being used and the sheer amount of crypto scams around.

VMG 4mo ago

I must admit I don't really understand what the point of the post-install script concern is. Usually, you run the actual packaged dependency code at some point anyway, and usually with the same permissions as the install process. So all of these setup scripts (good or bad) can just move their entrypoint from npm to wherever the `import` or `require` happens. It seems to me that this is a small stumbling block at best, unless the whole ecosystem moves to a deno-like sandboxed environment. Maybe that is the plan?

vbezhenar 4mo ago
You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE). I didn't try devcontainers stuff, TBH. But that's how I often develop my apps. That said, there are other attack surfaces for that approach. For example I'm not sure if I can trust LSP server not to execute application code. So keeping everything in a container or in a VM seems to be the only sane approach to work with code you don't trust.
- rafaelmn 4mo ago
  >You can build application outside of container, but run it in container. I think that it is simpler workflow, than everything in container (when you actually need to develop it with IDE). At this point I will not do any dev outside of a container - so many things can be supply chained in the OSS dev stack it's just not worth it, and once you get used to developing in containers it's actually a lot cleaner to move between hosts - you're essentially treating your client as a remote terminal. If you're doing web dev work in this day an age SSH with tmux or some editor with SSH server support should be your dev setup.
jeremyjh 4mo ago
A lot of packages are only used in the browser; if you don't use SSR they'd only be executed by node in unit tests in something like jest, but that is not the only way to run unit tests (Cypress can run them in a headless browser [1], for example). Running those sand-boxed would be the next logical step. Removing automated execution of postinstall is a necessary step and may as well be the first one. [1] https://docs.cypress.io/app/component-testing/get-started?utm_source=chatgpt.com https://docs.cypress.io/app/component-testing/get-started?ut...

hinkley 4mo ago

On a project with a 1GB node_modules directory (after aggressive cleanup) I think we only had one dependency that didn't work right with postinstall disabled. Though I can't recall which and I don't work there anymore so I can't hunt. And IIRC that one was fixable by a PR, because they'd done something weird and there was an idiomatic way to accomplish the same thing.