4 ms·

I accidentally typed 'npm install axioss' (extra s typo) this morning. When it successfully installed, it was terrifying to think that all source code, private

I accidentally typed 'npm install axioss' (extra s typo) this morning. When it successfully installed, it was terrifying to think that all source code, private files were instantly shared with malicious actors. Not only that, there was the prospect of having to somehow wipe and ensure all files were clean, reinstall the OS, and the possibility of some bootloader remnant still lurking. In this case, it seems that a security package had replaced a previous malicious package, making this instance benign. But it feels like I am only one typo away from an absolute catastrophe every time I install a package. VM seems like a good way to add some protection.

jeswin 2y ago
> VM seems like a good way to add some protection. Yeah, but someone should try to fix this anyway. It's not a nodejs-specific problem, but it's badly needed in node. Any of the 100s of authors whose packages I depend on might have made a typo, or just been careless. Software development requires a scary level of trust. I am also increasingly moving to VMs. I want tools (such as VSCode) to run on the main machine, but actual execution to happen in the vm. It's a bit painful and a drag on productivity, especially debugging.
- skydhash 2y ago
  The one trick I found that work well is to move everything in the VM. I usually opt for either emacs or vim, and if I need an IDE, I install i3. It just takes a moment to copy my dotfiles over.
  - quectophoton 2y ago
    I'm doing something similar. My development environment for work is defined in a Dockerfile, and I have a small shell script whose only purpose is to call `docker run` with that image, mount a few volumes for caching, mount the CWD in "/workspace", and start a shell in there. Development is done with nvim. If I need Docker Compose, I run it from the host. For projects that I find unpleasant to work with in this way, I use GitHub Codespaces. I hadn't thought about using a GUI IDE from within a VM, so thanks to your comment (EDIT: and also the submitted article) I now have something new to try!
- fpoling 2y ago
  VSCode assumes that the remote side is trusted. So if VM is compromised, VSCode on the host can be compromised as well. For this reason I run VSCode inside the VM.
  - MajesticHobo2 2y ago
    Can you point me to some documentation or proof of concept for this? Would definitely like to change my workflow if this is the case.
- superb_dev 2y ago
  Have you looked into something like Qubes OS?
throw5959 2y ago
Bun package manager (compatible with NPM) doesn't execute any code during package installation.
- diggan 2y ago
  Except you "need" things like postinstall lifecycle hook for some things. So you add the specific package you wanna download to trustedDependencies (like you'd need to do with node-sass for example), and then we're back to it executing code after downloading, making compromises to upstream dangerous again. A lot better than npm that lets any package run postinstall for sure, but as always there are no silver bullets. Apparently there is also a default list of packages that are allowed to run scripts on download with Bun, FYI https://github.com/oven-sh/bun/blob/main/src/install/default-trusted-dependencies.txt https://github.com/oven-sh/bun/blob/main/src/install/default...
  - throw5959 2y ago
    It allows you to separate these steps and only execute the unsafe ones in a container but not having to do everything in there. Thanks for mentioning the default list! Good point.
homebrewer 2y ago
You can wrap node and its package manager into something like bubblewrap, which will remove access to basically everything but the project root directory (including your home directory with its browser profiles and ssh keys). I use this script with an additional seccomp filter that also denies access to privileged syscalls, but I don't remember where the filter came from, so I won't post it here — you won't be able to audit it easily as it's basically a compiled binary. https://0x0.st/8zWK.sh https://0x0.st/8zWK.sh Place the script anywhere and create symlinks named 'node'/'npm'/'yarn'/etc pointing to it, putting them into the start of your $PATH. Run your commands as usual. Use a 'bash' symlink to see what it looks like inside the sandbox. It's not as good as a VM, but much more convenient.

jeswin 2y ago

> VM seems like a good way to add some protection. Yeah, but someone should try to fix this anyway. It's not a nodejs-specific problem, but it's badly needed in node. Any of the 100s of authors whose packages I depend on might have made a typo, or just been careless. Software development requires a scary level of trust. I am also increasingly moving to VMs. I want tools (such as VSCode) to run on the main machine, but actual execution to happen in the vm. It's a bit painful and a drag on productivity, especially debugging.

skydhash 2y ago
The one trick I found that work well is to move everything in the VM. I usually opt for either emacs or vim, and if I need an IDE, I install i3. It just takes a moment to copy my dotfiles over.
- quectophoton 2y ago
  I'm doing something similar. My development environment for work is defined in a Dockerfile, and I have a small shell script whose only purpose is to call `docker run` with that image, mount a few volumes for caching, mount the CWD in "/workspace", and start a shell in there. Development is done with nvim. If I need Docker Compose, I run it from the host. For projects that I find unpleasant to work with in this way, I use GitHub Codespaces. I hadn't thought about using a GUI IDE from within a VM, so thanks to your comment (EDIT: and also the submitted article) I now have something new to try!
fpoling 2y ago
VSCode assumes that the remote side is trusted. So if VM is compromised, VSCode on the host can be compromised as well. For this reason I run VSCode inside the VM.
- MajesticHobo2 2y ago
  Can you point me to some documentation or proof of concept for this? Would definitely like to change my workflow if this is the case.
superb_dev 2y ago
Have you looked into something like Qubes OS?

throw5959 2y ago

Bun package manager (compatible with NPM) doesn't execute any code during package installation.

diggan 2y ago
Except you "need" things like postinstall lifecycle hook for some things. So you add the specific package you wanna download to trustedDependencies (like you'd need to do with node-sass for example), and then we're back to it executing code after downloading, making compromises to upstream dangerous again. A lot better than npm that lets any package run postinstall for sure, but as always there are no silver bullets. Apparently there is also a default list of packages that are allowed to run scripts on download with Bun, FYI https://github.com/oven-sh/bun/blob/main/src/install/default-trusted-dependencies.txt https://github.com/oven-sh/bun/blob/main/src/install/default...
- throw5959 2y ago
  It allows you to separate these steps and only execute the unsafe ones in a container but not having to do everything in there. Thanks for mentioning the default list! Good point.

homebrewer 2y ago

You can wrap node and its package manager into something like bubblewrap, which will remove access to basically everything but the project root directory (including your home directory with its browser profiles and ssh keys). I use this script with an additional seccomp filter that also denies access to privileged syscalls, but I don't remember where the filter came from, so I won't post it here — you won't be able to audit it easily as it's basically a compiled binary. https://0x0.st/8zWK.sh https://0x0.st/8zWK.sh Place the script anywhere and create symlinks named 'node'/'npm'/'yarn'/etc pointing to it, putting them into the start of your $PATH. Run your commands as usual. Use a 'bash' symlink to see what it looks like inside the sandbox. It's not as good as a VM, but much more convenient.