4 ms·

Package maintainers implement install scripts for a reason. It should be opt-out, not opt-in. There should be granualar control over which packages, and which

Package maintainers implement install scripts for a reason. It should be opt-out, not opt-in. There should be granualar control over which packages, and which scripts you want to block. E.g in your package.json: `"scriptblock": { "puppeteer" : "*" } ` or ` "scriptblock": { "puppeteer" : ["preinstall","postinstall"...] } ` etc.

d4mi3n 5y ago
Sadly security by blacklisting always turns into a game of whack-as-mole. If there’s an unavoidable need for an install script that may be a case to mature the facilities a package manager offers rather than requiring packages to run arbitrary code.
axlee 5y ago
You have no idea of the packages you are installing. Like litterally, none, unless you use very narrow, pure-js ones. Nobody can grok the dependency tree of the top 50 popular packages. Asking for opt-out is the best way for nothing to happen.
pxc 5y ago
> Package maintainers implement install scripts for a reason. It should be opt-out, not opt-in. yeah, because they're allowed to. The only time that install scripts are sane and reliable is when they are part of a community that polices them and requires them to be minimal (e.g., in Linux distros). That's basically never the case with language-specific package managers
- smashah 5y ago
  Almost all npm packages are open and the code available in Github - so if npm package maintainers are not being policed then it's the community's fault for leeching and not looking into the code. I run an install script for my package [0], this install script forces 2 lines in users' .gitignore files to prevent EXTREMELY sensitive data being committed into a public repo - despite me telling everyone in the community to not commit these files on god-knows how many occasions. I do this because I care about my users and I know if I tried some funny business then they would rightly call me out for it - NOT "because I'm allowed to". [0] - https://github.com/open-wa/wa-automate-nodejs/blob/0ba7d685066956949a6543e194d85845f8361649/package.json#L31 https://github.com/open-wa/wa-automate-nodejs/blob/0ba7d6850...
tolmasky 5y ago
At RunKit, we've actually installed every version of every package, and I can assure you that it is not the case that there's tons of packages using install scripts for really great reasons. For starters, the vast majority of packages do not use this feature. Then, you have to consider that install scripts are a very old feature designed for a series of constraints that are either no longer representative of the state of the ecosystem, or quickly won't be. For example: 1. The most "legitimate" use of install scripts is to build binary node addons. N-API is a much better alternative with ABI compatibility that will allow the package to just ship built, which aside from being a much friendlier and faster install experience, will also allow for more deterministic builds and better caching. 2. Many install scripts just transpile code on installation. It would be much better to instead just transpile the code on publish. This is something that requires nothing new and everyone should absolutely just do today. It's crazy that people re-download and retranspile the same code over and over. 3. Many install scripts simply download non-npm resources, like apt dependencies or things like Chromium. It would be a lot better, a decade after npm's introduction, to standardize this common use case like this instead of having everyone roll their own. We actually implemented our own version of this where we can just list apt dependencies in our package.json. It gives you so many more options on how to optimize builds and provides you so much better information about your dependencies to have this be a "declarative" piece of the puzzle as opposed to having every package figure out their own slightly different way of doing this. 4. Many install scripts just present the user with ads. NPM should also just add a package.json field for donation links or whatever and provide a good standard way of disabling this as opposed to spinning up a process just to present ads. 5. And of course, some install scripts are used maliciously. All this to say, 10 years later, there aren't actually a bunch of "wow, what an interesting use of the install script" examples, but rather just a bunch of fairly limited common uses (that could be better handled by npm itself), and yes, some interesting stuff, but also a worrying amount of abuses, that are easily duplicated and that we are currently doing nothing to stop. Given a proper transitional period, where npm just warns you above an install script rather than failing, I think most packages could be made to not require custom install scripts. And again, this is for a small percentage of packages, nowhere near the undertaking of converting packages on NPM from CommonJS to ESM for example. And, it's not that it would be disallowed, it's just that the rare package that really did need to do something really out there would need a flag. Having actually queried all the packages, I am certain this could be done with basically no disruption for end users, certainly no disruption to most package authors that don't use these scripts, and almost no disruption for the few package authors that currently use this feature.
seniorsassycat 5y ago
Then those packages should explain their reason and ask for permission. Default should be opt-in.

d4mi3n 5y ago

Sadly security by blacklisting always turns into a game of whack-as-mole. If there’s an unavoidable need for an install script that may be a case to mature the facilities a package manager offers rather than requiring packages to run arbitrary code.

axlee 5y ago

You have no idea of the packages you are installing. Like litterally, none, unless you use very narrow, pure-js ones. Nobody can grok the dependency tree of the top 50 popular packages. Asking for opt-out is the best way for nothing to happen.

pxc 5y ago

> Package maintainers implement install scripts for a reason. It should be opt-out, not opt-in. yeah, because they're allowed to. The only time that install scripts are sane and reliable is when they are part of a community that polices them and requires them to be minimal (e.g., in Linux distros). That's basically never the case with language-specific package managers

smashah 5y ago
Almost all npm packages are open and the code available in Github - so if npm package maintainers are not being policed then it's the community's fault for leeching and not looking into the code. I run an install script for my package [0], this install script forces 2 lines in users' .gitignore files to prevent EXTREMELY sensitive data being committed into a public repo - despite me telling everyone in the community to not commit these files on god-knows how many occasions. I do this because I care about my users and I know if I tried some funny business then they would rightly call me out for it - NOT "because I'm allowed to". [0] - https://github.com/open-wa/wa-automate-nodejs/blob/0ba7d685066956949a6543e194d85845f8361649/package.json#L31 https://github.com/open-wa/wa-automate-nodejs/blob/0ba7d6850...

tolmasky 5y ago

At RunKit, we've actually installed every version of every package, and I can assure you that it is not the case that there's tons of packages using install scripts for really great reasons. For starters, the vast majority of packages do not use this feature. Then, you have to consider that install scripts are a very old feature designed for a series of constraints that are either no longer representative of the state of the ecosystem, or quickly won't be. For example: 1. The most "legitimate" use of install scripts is to build binary node addons. N-API is a much better alternative with ABI compatibility that will allow the package to just ship built, which aside from being a much friendlier and faster install experience, will also allow for more deterministic builds and better caching. 2. Many install scripts just transpile code on installation. It would be much better to instead just transpile the code on publish. This is something that requires nothing new and everyone should absolutely just do today. It's crazy that people re-download and retranspile the same code over and over. 3. Many install scripts simply download non-npm resources, like apt dependencies or things like Chromium. It would be a lot better, a decade after npm's introduction, to standardize this common use case like this instead of having everyone roll their own. We actually implemented our own version of this where we can just list apt dependencies in our package.json. It gives you so many more options on how to optimize builds and provides you so much better information about your dependencies to have this be a "declarative" piece of the puzzle as opposed to having every package figure out their own slightly different way of doing this. 4. Many install scripts just present the user with ads. NPM should also just add a package.json field for donation links or whatever and provide a good standard way of disabling this as opposed to spinning up a process just to present ads. 5. And of course, some install scripts are used maliciously. All this to say, 10 years later, there aren't actually a bunch of "wow, what an interesting use of the install script" examples, but rather just a bunch of fairly limited common uses (that could be better handled by npm itself), and yes, some interesting stuff, but also a worrying amount of abuses, that are easily duplicated and that we are currently doing nothing to stop. Given a proper transitional period, where npm just warns you above an install script rather than failing, I think most packages could be made to not require custom install scripts. And again, this is for a small percentage of packages, nowhere near the undertaking of converting packages on NPM from CommonJS to ESM for example. And, it's not that it would be disallowed, it's just that the rare package that really did need to do something really out there would need a flag. Having actually queried all the packages, I am certain this could be done with basically no disruption for end users, certainly no disruption to most package authors that don't use these scripts, and almost no disruption for the few package authors that currently use this feature.

seniorsassycat 5y ago

Then those packages should explain their reason and ask for permission. Default should be opt-in.