Very cool idea. Thanks for sharing. I made some minor tweaks based on feedback to your comment:

  #!/usr/bin/env bash
  #
  # See: https://news.ycombinator.com/item?id=45034496
  
  bin=$(basename "$0")
  
  echo "==========================="
  echo "Wrapping $bin in bubblewrap"
  echo "==========================="
  
  exec bwrap \
    --bind ~/.cache ~/.cache \
    --bind "${PWD}" "${PWD}" \
    --dev /dev \
    --die-with-parent \
    --disable-userns \
    --new-session \
    --proc /proc \
    --ro-bind /etc/ca-certificates /etc/ca-certificates \
    --ro-bind /etc/resolv.conf /etc/resolv.conf \
    --ro-bind /etc/ssl /etc/ssl \
    --ro-bind /usr /usr \
    --setenv PATH /usr/bin \
    --symlink /usr/bin /bin \
    --symlink /usr/bin /sbin \
    --symlink /usr/lib /lib \
    --symlink /usr/lib64 /lib64 \
    --tmpfs /tmp \
    --unshare-all \
    --unshare-user \
    --share-net \
    /usr/bin/env "$bin" "$@"

Thanks, handy wrapper :) Note:

    --symlink /usr/lib /lib64 \

and

    --share-net \

Also, my system doesn't have a symlink from /tmp to /var/tmp, so I'm guessing that's not needed for me (while /bin etc. are symlinks)

Very cool. Hadn't heard of this before. I appreciate you posting it.

Will this work on osX? and for pnpm?

Firejail is quite good, too. I have been using firejail more than bubblewrap.

This is trading one distribution problem (npx) for another (bubblewrap). I think it’s a reasonable trade, but there’s no free lunch.

pnpm is not only more secure, it's also faster, more efficient wrt disk usage, and more deterministic by design.

Same for bun, which I find faster than pnpm

This is the way. It’s a pain to manually disable the checks, but certainly better than becoming victim to an attack like this.

Yeah I guess it probably helps you specifically, because most malware is going to do the lazy thing and use install scripts. But it doesn't help everyone in general because if e.g. NPM disabled those scripts entirely (or made them opt-in) then the malware authors would just put their malware into the `npm run` as you say.

It should apply for anything. Truth be told the process of learning programming is so arduous at times that you basically just copy and paste and run fucking anything in terminal to get a project setup or fixed.

Go down the rabbit hole of just installing LLM software and you’ll find yourself in quite a copy and paste frenzy.

We got used to this GitHub shit of setting up every process of an install script in this way, so I’m surprised it’s not happening constantly.

It should, and also to Makefile.PL, etc. These systems were created at a time when you were dealing with a handful of dependencies, and software development was a friendlier place.

Now you're dealing with hundreds of recursive dependencies, all of which you should assume may become hostile at any time. If you neither audit your dependencies, nor have the ability to sue them for damages, you're in a precarious position.

For simple python libraries setup.py has been discouraged for a long time in favour of pyproject.toml for exactly this reason

Downloading binaries as part of an installation of a scripting language library should always be assumed to be malicious.

Everything must be provided as source code and any compilation must happen locally.

You can still whitelist them, though, and reinstall them.

According to the description in advisory, this attack was in a postinstall script. So it would've helped in this case with nx. Even if you ran the tool, this particular attack wouldn't have been triggered if you had install scripts ignored.

I work for a company that needs to ship software so my salary can get paid

> As a linux admin, I refuse to install npm or anything that requires it as a dep. It's been bad since the start.

As a front-end web developer, I need a node package manager; and npm comes bundled with node.