4 ms·

I don't understand why people keep endlessly complaining about postinstall scripts. Such 'nagging donation requests' were banned by npm pretty much days after

I don't understand why people keep endlessly complaining about postinstall scripts. Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, and npm itself is literally a tool for installing code to execute later, so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. This is really a complete nothingburger.

minitech 6y ago
“install” and “execute later” don’t always involve the same permissions. If you apply restrictive sandboxes your code, package managers that aren’t designed to be able to download untrusted code are annoying. Of course, this problem isn’t unique to npm. (It’s actually the opposite – all you need to do with npm is --ignore-scripts, whereas pretty much every other popular package manager I use just makes it impossible.) And yes, you want to sandbox the install too anyway, but it at least needs permissions enough to do its job, i.e. interact with the network somehow. (Although I’m working on a tool to make that fully deterministic so it can never exfiltrate anything.) There’s also the possibility that there’s no “execute” step at all, like installing a dependency tree just to inspect source, or in theory being able to skip auditing unused code paths.
- seg_lol 6y ago
  Keep editing, we will wait. Eventually you containerize the container and realize that only a single if is enough for everyone.
  - minitech 6y ago
    > Eventually you containerize the container and realize that only a single if is enough for everyone. You either have a typo somewhere or are not being very clear. Either way, keep editing.
    - seg_lol 6y ago
      That was a sweet self own. I really enjoyed this.
koolba 6y ago
> Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, What does "banned by npm" mean? Here's an example from the source of the latest version of nodemailer (with 1.4M weekly downloads) sleeping for 4,100 ms on every install so that it can show a "Sponsor us to remove this lag" message: https://github.com/nodemailer/nodemailer/blob/a455716a22d22f80e1ffdfd7171e92123ab38cc8/postinstall.js#L96-L101 https://github.com/nodemailer/nodemailer/blob/a455716a22d22f... > and npm itself is literally a tool for installing code to execute later, so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. It's fine to have a standard mechanism for postinstall steps. It should be opt-in by the end user rather than opt-out. That way people know that they're running additional code and ideally selectively pick which packages are allowed to do so. The vast majority of packages do not need it anyway as they do not have C++ bindings or need to generate data. The defaults for NPM are such that you have to know quite a bit of how NPM works to download a package and inspect the contents without executing random code. > This is really a complete nothingburger. It's defensive in depth. With the default being to execute remote code, a single typo could be installing a package that immediately runs malware.

minitech 6y ago

“install” and “execute later” don’t always involve the same permissions. If you apply restrictive sandboxes your code, package managers that aren’t designed to be able to download untrusted code are annoying. Of course, this problem isn’t unique to npm. (It’s actually the opposite – all you need to do with npm is --ignore-scripts, whereas pretty much every other popular package manager I use just makes it impossible.) And yes, you want to sandbox the install too anyway, but it at least needs permissions enough to do its job, i.e. interact with the network somehow. (Although I’m working on a tool to make that fully deterministic so it can never exfiltrate anything.) There’s also the possibility that there’s no “execute” step at all, like installing a dependency tree just to inspect source, or in theory being able to skip auditing unused code paths.

seg_lol 6y ago
Keep editing, we will wait. Eventually you containerize the container and realize that only a single if is enough for everyone.
- minitech 6y ago
  > Eventually you containerize the container and realize that only a single if is enough for everyone. You either have a typo somewhere or are not being very clear. Either way, keep editing.
  - seg_lol 6y ago
    That was a sweet self own. I really enjoyed this.

koolba 6y ago

> Such 'nagging donation requests' were banned by npm pretty much days after they first appeared, IIRC, What does "banned by npm" mean? Here's an example from the source of the latest version of nodemailer (with 1.4M weekly downloads) sleeping for 4,100 ms on every install so that it can show a "Sponsor us to remove this lag" message: https://github.com/nodemailer/nodemailer/blob/a455716a22d22f80e1ffdfd7171e92123ab38cc8/postinstall.js#L96-L101 https://github.com/nodemailer/nodemailer/blob/a455716a22d22f... > and npm itself is literally a tool for installing code to execute later, so there's no security issue here. If someone wanted to embed malware into a package, they wouldn't need postinstall scripts for it. It's fine to have a standard mechanism for postinstall steps. It should be opt-in by the end user rather than opt-out. That way people know that they're running additional code and ideally selectively pick which packages are allowed to do so. The vast majority of packages do not need it anyway as they do not have C++ bindings or need to generate data. The defaults for NPM are such that you have to know quite a bit of how NPM works to download a package and inspect the contents without executing random code. > This is really a complete nothingburger. It's defensive in depth. With the default being to execute remote code, a single typo could be installing a package that immediately runs malware.