[HN Gopher] Getting rid of NPM scripts ___________________________________________________________________ Getting rid of NPM scripts Author : efortis Score : 17 points Date : 2020-12-26 21:06 UTC (1 hours ago) (HTM) web link (blog.uidrafter.com) (TXT) w3m dump (blog.uidrafter.com) | dblotsky wrote: | The `./make` shell script kills me. Why not just use Make? | smichel17 wrote: | And as an added bonus, Make gives you tab autocompletion | slmjkdbtl wrote: | (not strong arguments but some possible explanations) | | 1) ./make can be more portable e.g. you might use some GNU Make | syntax that does not run on BSD and have to insall gmake just | to run that | | 2) Make is not designed to be a command runner and have to | manually add .PHONY to everything | | 3) case looks minimal and flexible enough (although I'm sure | sh's confusing syntax can cause a lot of pain for non sh | experts) | tobyhinloopen wrote: | Once a package is "hijacked" like this, it might as well contain | a spawn(...) command in the JS code. | coffeefirst wrote: | Right. The scary part is not code you're running can do | something bad. Of course it can. | | It's that given the depth of the dependency trees, I don't have | any confidence we can tell the difference between trustworthy | and untrustworthy packages. | efortis wrote: | I agree, but that's a different attack vector, and doesn't | render this mitigation useless. @haburka gave an example for | that. | Waterluvian wrote: | I love git open[0] but I was always a bit mystified by how a | simple "npm install" command can modify what it needs to in order | for "git open" to become a valid command. | | It's convenient but, in my opinion, at a cost of "magic" being | done to my machine with a "don't worry about it" attitude. | | A UX I could get down with would be "npx run git-open" followed | by a short CLI that tells me what it's about to do, why, and asks | for confirmation. | | [0]https://github.com/paulirish/git-open | burnthrow wrote: | Git will fallback to `git-$command` for any unknown command. | That tool works by installing an executable at `git-open`. It | works "magically" with npx because npx is installing it for | you. | jessaustin wrote: | How many people are this careful about install scripts, but then | allow the installed code to run with just the same permissions as | the install script would have run? Is that a meaningful | difference? Is it more difficult to audit install scripts than to | audit the rest of the code? | haburka wrote: | Actually the installed code may have less permissions and may | execute in a different context. For example, an npm js library | for a photo gallery may only ever run in the context of the | browser. Of course some libraries for server code / build code | may run in node js which ostensibly allows for ACE. But the | surface area is smaller with this. | burnthrow wrote: | Install scripts typically have access to build environments. | dec0dedab0de wrote: | I only use npm to install frontend libraries, so the installed | code is limited by the browser when it runs. | | As far as I know the install scripts can do anything they want, | which is upsetting whenever I think about it or they try to do | something that annoys the corporate web proxy. | | I bet an install script that dumped environment variables, then | encoded them into something seemingly innocent like the extra | fields of a dns request would gather all kinds of fun info from | all the different ci/cd systems. | est31 wrote: | Install scripts are kinda like make install, with which I had | bad experiences. Often there is no command to uninstall again, | and even if, can you trust that it works and really uninstalls | stuff cleanly? What if there is an error in one half of the | execution? Scripts are not a good way to install software. Do | everything with declarative schemes if you can. Then have the | runtime deal with partial installs/uninstalls etc. | | This is less of a security issue and more of a conventions | issue. Also, install scripts often run as root instead of the | compiling user. ___________________________________________________________________ (page generated 2020-12-26 23:00 UTC)