4 ms·

I strongly support this. There are of course other ways of compromising peoples computers when running untrusted code, but let’s get the low hanging fruit. I h

I strongly support this. There are of course other ways of compromising peoples computers when running untrusted code, but let’s get the low hanging fruit. I have a very simple vue frontend app that I wrote a few years ago, and it somehow has >4000 dependencies (including dev dependencies). The fact that npm install could run code from all of those (which might not be obvious to a newer dev) is flat out dangerous.

echelon 5y ago
If we're going to develop our software like this (there are no signs of changing), then we need development environments that are fully hermetic. Production deploys tend to be if you use the right tools. Docker images, cert signing, ACLs, network policies, etc. But we have no equivalent for developer machines. And engineers have access to lots of dangerous things. Docker alone isn't good enough.
- noodlesUK 5y ago
  I've recently switched from linux to MacOS (now that those shiny new MacBook Pros exist), and due to this, I've started using vscode dev containers along with gitpod as my pretty much exclusive development environments. I did this for convenience rather than for security, but I must say I felt a strong feeling of relief when this morning I saw the advisory, and typed `npm` into my terminal and found that it wasn't even installed on my host OS. I think longer term, we're going to find things like Qubes's VM for everything model becoming more normalised.
- endgame 5y ago
  Nix?
  - pxc 5y ago
    I think they mean 'hermetic' in a more restrictive sense. But you can use Nix to generate Docker images and VMs and stuff, so you could use Nix to produce environments that are sandboxed if you want. And builds are sandboxed, which helps with the OP issue
- codethief 5y ago
  This. I would love to have a minimal host machine setup while having all those elaborate dev dependencies and command line tools I downloaded from somewhere run inside their own isolated container (or at least within one single container for my entire $SOFTWARE_PROJECT). Basically, I'm trying to imagine a world where every Bash script needs to come with headers specifiying binary dependencies and file paths (and env vars) it wants to access. Upon invoking said script, it gets executed within a light-weight container, the binary dependencies then get installed on-the-fly and the file paths get mounted into the container (after I've confirmed that the script may access them).
  - pxc 5y ago
    > Basically, I'm trying to imagine a world where every Bash script needs to come with headers specifiying binary dependencies and file paths (and env vars) it wants to access. Upon invoking said script, it gets executed within a light-weight container, the binary dependencies then get installed on-the-fly and the file paths get mounted into the container (after I've confirmed that the script may access them). There are pieces of this that have been implemented in Nix, Distri, and Flatpak. Binary dependencies getting installed on the fly used to be something you could enable systemwide on NixOS, and parts of it still can be. There are also FUSE filesystems that can automatically build/fetch paths as they're requested. DwarfFS, for fetching debug symbols, is the first one I'd heard of, and then there were some experiments like this in Distri. In Nixpkgs, scripts built by b Nix are created in a way that bundles in the executables they call by interpolating in full paths to deterministically built versions. In Flatpak you have this notion of portals, where you declare file paths and other things where your program is allowed to talk to anything else. It seems a little more seamless than sharing the filesystem on Docker. I think this is pretty achievable in the moderate term.
    - codethief 5y ago
      I'm aware of Nix and know this is achievable – in theory. To really work well and be convenient it would have to be used everywhere, though. https://xkcd.com/927/ https://xkcd.com/927/ comes to mind.
- deckard1 5y ago
  Why not a virtual machine? I've been doing that for nearly a decade now. Back when it was actually sort of painful. Now we have 32+ gigs of RAM and 8 core CPUs. You get snapshots and if your drive image is small enough you can toss it on a USB SSD drive and take it wherever you need to. Docker was never good enough. Especially if you're on a Mac. It's a Linux VM with more overhead added and greater access to the host making it less secure than just using a VM in the first place.
throwaway821909 5y ago
The actual build that you provide to customers will run code from many/most/nearly all of them, I think your dev machine is the least of your worries
- bpicolo 5y ago
  That's definitely relevant for nodejs apps, but running js client side is a very different risk profile from running arbitrary scripts on the computer or server doing an npm install.
- noodlesUK 5y ago
  You might think that, but if we’re talking about a frontend service that doesn’t really handle much sensitive info (if any), there’s a lot juicier stuff on my machine than just pushing malware to that codebase (not least other codebases on my machines)
WhyNotHugo 5y ago
Suppose you prevent those 4k+ libraries from running code during install: you're building software that you'll run immediately afterwards. If you don't trust those libraries enough to run code during installation, why do you trust them enough to run code _after_ installation?

echelon 5y ago

If we're going to develop our software like this (there are no signs of changing), then we need development environments that are fully hermetic. Production deploys tend to be if you use the right tools. Docker images, cert signing, ACLs, network policies, etc. But we have no equivalent for developer machines. And engineers have access to lots of dangerous things. Docker alone isn't good enough.

noodlesUK 5y ago
I've recently switched from linux to MacOS (now that those shiny new MacBook Pros exist), and due to this, I've started using vscode dev containers along with gitpod as my pretty much exclusive development environments. I did this for convenience rather than for security, but I must say I felt a strong feeling of relief when this morning I saw the advisory, and typed `npm` into my terminal and found that it wasn't even installed on my host OS. I think longer term, we're going to find things like Qubes's VM for everything model becoming more normalised.
endgame 5y ago
Nix?
- pxc 5y ago
  I think they mean 'hermetic' in a more restrictive sense. But you can use Nix to generate Docker images and VMs and stuff, so you could use Nix to produce environments that are sandboxed if you want. And builds are sandboxed, which helps with the OP issue
codethief 5y ago
This. I would love to have a minimal host machine setup while having all those elaborate dev dependencies and command line tools I downloaded from somewhere run inside their own isolated container (or at least within one single container for my entire $SOFTWARE_PROJECT). Basically, I'm trying to imagine a world where every Bash script needs to come with headers specifiying binary dependencies and file paths (and env vars) it wants to access. Upon invoking said script, it gets executed within a light-weight container, the binary dependencies then get installed on-the-fly and the file paths get mounted into the container (after I've confirmed that the script may access them).
- pxc 5y ago
  > Basically, I'm trying to imagine a world where every Bash script needs to come with headers specifiying binary dependencies and file paths (and env vars) it wants to access. Upon invoking said script, it gets executed within a light-weight container, the binary dependencies then get installed on-the-fly and the file paths get mounted into the container (after I've confirmed that the script may access them). There are pieces of this that have been implemented in Nix, Distri, and Flatpak. Binary dependencies getting installed on the fly used to be something you could enable systemwide on NixOS, and parts of it still can be. There are also FUSE filesystems that can automatically build/fetch paths as they're requested. DwarfFS, for fetching debug symbols, is the first one I'd heard of, and then there were some experiments like this in Distri. In Nixpkgs, scripts built by b Nix are created in a way that bundles in the executables they call by interpolating in full paths to deterministically built versions. In Flatpak you have this notion of portals, where you declare file paths and other things where your program is allowed to talk to anything else. It seems a little more seamless than sharing the filesystem on Docker. I think this is pretty achievable in the moderate term.
  - codethief 5y ago
    I'm aware of Nix and know this is achievable – in theory. To really work well and be convenient it would have to be used everywhere, though. https://xkcd.com/927/ https://xkcd.com/927/ comes to mind.
deckard1 5y ago
Why not a virtual machine? I've been doing that for nearly a decade now. Back when it was actually sort of painful. Now we have 32+ gigs of RAM and 8 core CPUs. You get snapshots and if your drive image is small enough you can toss it on a USB SSD drive and take it wherever you need to. Docker was never good enough. Especially if you're on a Mac. It's a Linux VM with more overhead added and greater access to the host making it less secure than just using a VM in the first place.

throwaway821909 5y ago

The actual build that you provide to customers will run code from many/most/nearly all of them, I think your dev machine is the least of your worries

bpicolo 5y ago
That's definitely relevant for nodejs apps, but running js client side is a very different risk profile from running arbitrary scripts on the computer or server doing an npm install.
noodlesUK 5y ago
You might think that, but if we’re talking about a frontend service that doesn’t really handle much sensitive info (if any), there’s a lot juicier stuff on my machine than just pushing malware to that codebase (not least other codebases on my machines)

WhyNotHugo 5y ago

Suppose you prevent those 4k+ libraries from running code during install: you're building software that you'll run immediately afterwards. If you don't trust those libraries enough to run code during installation, why do you trust them enough to run code _after_ installation?