Most active commenters

    ←back to thread

    Malicious versions of Nx and some supporting plugins were published

    (github.com)
    441 points longcat | 14 comments | 27 Aug 25 01:38 UTC | HN request time: 0.001s | source | bottom
    Show context
    inbx0 ◴[27 Aug 25 14:33 UTC] No.45040282[source]▶
    Periodic reminder to disable npm install scripts.

        npm config set ignore-scripts true [--global]
    It's easy to do both at project level and globally, and these days there are quite few legit packages that don't work without them. For those that don't, you can create a separate installation script to your project that cds into that folder and runs their install-script.

    I know this isn't a silver bullet solution to supply chain attakcs, but, so far it has been effective against many attacks through npm.

    https://docs.npmjs.com/cli/v8/commands/npm-config

    replies(17): >>45040489 #>>45041292 #>>45041798 #>>45041820 #>>45041840 #>>45042872 #>>45043977 #>>45045311 #>>45045447 #>>45045979 #>>45046082 #>>45046981 #>>45047430 #>>45047994 #>>45049197 #>>45049793 #>>45050820 #
    homebrewer ◴[27 Aug 25 16:27 UTC] No.45041798[source]▶
    I also use bubblewrap to isolate npm/pnpm/yarn (and everything started by them) from the rest of the system. Let's say all your source code resides in ~/code; put this somewhere in the beginning of your $PATH and name it `npm`; create symlinks/hardlinks to it for other package managers:

      #!/usr/bin/bash

  bin=$(basename "$0")

  exec bwrap \
    --bind ~/.cache/nodejs ~/.cache \
    --bind ~/code ~/code \
    --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 \
    --share-net \
    --symlink /tmp /var/tmp \
    --symlink /usr/bin /bin \
    --symlink /usr/bin /sbin \
    --symlink /usr/lib /lib \
    --symlink /usr/lib /lib64 \
    --tmpfs /tmp \
    --unshare-all \
    --unshare-user \
    "/usr/bin/$bin" "$@"
    The package manager started through this script won't have access to anything but ~/code + read-only access to system libraries:

      bash-5.3$ ls -a ~
  .  ..  .cache  code
    bubblewrap is quite well tested and reliable, it's used by Steam and (IIRC) flatpak.
    replies(7): >>45043567 #>>45045504 #>>45046093 #>>45049572 #>>45049755 #>>45053685 #>>45092016 #
    1. shermantanktop ◴[27 Aug 25 18:57 UTC] No.45043567[source]▶
    This is trading one distribution problem (npx) for another (bubblewrap). I think it’s a reasonable trade, but there’s no free lunch.
    replies(1): >>45045056 #
    2. homebrewer ◴[27 Aug 25 20:49 UTC] No.45045056[source]▶
    Not sure what this means. bubblewrap is as free as it gets, it's just a thin wrapper around the same kernel mechanisms used for containers, except that it uses your existing filesystems instead of creating a separate "chroot" from an OCI image (or something like it).

    The only thing it does is hiding most of your system from the stuff that runs under it, whitelisting specific paths, and optionally making them readonly. It can be used to run npx, or anything else really — just shove move symblinks into the beginning of your $PATH, each referencing the script above. Run any of them and it's automatically restricted from accessing e.g. your ~/.ssh

    https://wiki.archlinux.org/title/Bubblewrap

    replies(1): >>45045600 #
    3. conception ◴[27 Aug 25 21:36 UTC] No.45045600[source]▶
    It means that someone just has to compromise bubblewrap instead of the other vectors.
    replies(5): >>45045751 #>>45045980 #>>45046340 #>>45047397 #>>45049907 #
    4. cozzyd ◴[27 Aug 25 21:50 UTC] No.45045751{3}[source]▶
    sure but surely one gets bubblewrap from their distro, and you have to trust your distro anyway.
    5. theamk ◴[27 Aug 25 22:12 UTC] No.45045980{3}[source]▶
    Not "instead", it's "in addition to". Your classical defense-in-depth.
    replies(1): >>45046101 #
    6. oulipo2 ◴[27 Aug 25 22:25 UTC] No.45046101{4}[source]▶
    No, "instead". If they compromise bubblewrap to send out your files, and you run bubblewrap anyway for any reason, you're still compromised.

    But obviously you can probably safely pin bubblewrap to a given version, and you don't need to "install packages through it", which is the main weakness of package managers

    replies(2): >>45050728 #>>45050891 #
    7. haswell ◴[27 Aug 25 22:56 UTC] No.45046340{3}[source]▶
    While this may be true, this is still a major improvement, no?

    i.e. it seems far more likely that a rapidly evolving hot new project will be targeted vs. something more stable and explicitly security focused like bubblewrap.

    8. throwawaysoxjje ◴[28 Aug 25 01:47 UTC] No.45047397{3}[source]▶
    Am I getting bubblewrap somewhere other than my distro? What makes it different from any other executable that comes from there?
    replies(1): >>45054097 #
    9. johnisgood ◴[28 Aug 25 08:45 UTC] No.45049907{3}[source]▶
    This is such a defeatist perspective. You could say this about anything ad nauseum. I think bubblewrap (or firejail) is less likely to be a successful target.
    10. aragilar ◴[28 Aug 25 11:08 UTC] No.45050728{5}[source]▶
    How? bubblewrap isn't something someone has randomly uploaded to npm, it has well known maintainers and a well organised release process (including package signing). Which is easier to do: upload a package to npm and get people to use it, or spend 2+ years trying to become a maintainer of bubblewrap or one of its dependencies to compromise it.
    replies(1): >>45051693 #
    11. ChocolateGod ◴[28 Aug 25 11:32 UTC] No.45050891{5}[source]▶
    Bubblewrap uses the same Linux functions that billion dollar cloud infrastructure use. Bubblewrap does no sandboxing/restrictions itself, it's instructing the kernel to do it.
    12. oulipo2 ◴[28 Aug 25 13:06 UTC] No.45051693{6}[source]▶
    Sure, but there's plenty of packages with well-known maintainers who get compromised...
    replies(1): >>45052173 #
    13. haswell ◴[28 Aug 25 13:49 UTC] No.45052173{7}[source]▶
    The fact that something can happen is separate from how likely that thing is to happen, and that’s what matters here.

    The comments here that point to this theoretical possibility seem to be missing the point, which is that using something like bubblewrap is an improvement over running arbitrary projects un-sandboxed, and the likelihood of such an attack is far less than the likelihood of any one of hundreds of rapidly evolving, lesser known, lesser scrutinized projects getting compromised.

    14. shermantanktop ◴[28 Aug 25 16:27 UTC] No.45054097{4}[source]▶
    Nothing. Does your threat model assume 100% trust in your distro? I understand saying you trust it a lot more than the garbage on npm. But if your trust is anything less than 100%, you are balancing risk and benefit.