← Back to context

Comment by qubex

7 hours ago

About a month ago I had a rather annoying task to perform, and I found an NPM package that handled it. I threw “brew install NPM” or whatever onto the terminal and watched a veritable deluge of dependencies download and install. Then I typed in ‘npm ’ and my hand hovered on the keyboard after the space as I suddenly thought long and hard about where I was on the risk/benefit curve and then I backspaced and typed “brew uninstall npm” instead, and eventually strung together an oldschool unix utilities pipeline with some awk thrown in. Probably the best decision of my life, in retrospect.

This is why you want containerisation or, even better, full virtualisation. Running programs built on node, python or any other ecosystem that makes installing tons of dependencies easy (and thus frustratingly common) on your main system where you keep any unrelated data is a surefire way to get compromised by the supply chain eventually. I don't even have the interpreters for python and js on my base system anymore - just so I don't accidentally run something in the host terminal that shouldn't run there.

  • No thats not what i want, that whats i need when i use something like npm.

    Which can't be the right way.

    • Why not? Make a bash alias for `npm` that runs it with `bwrap` to isolate it to the current directory, and you don't have to think about it again. Distributions could have a package that does this by default. With nix, you don't even need npm in your default profile, and can create a sandboxed nix-shell on the fly so that's the only way for the command to even be available.

      Most of your programs are trusted, don't need isolation by default, and are more useful when they have access to your home data. npm is different. It doesn't need your documents, and it runs untrusted code. So add the 1 line you need to your profile to sandbox it.

    • The right way (technically) and the commercially viable way are often diametrically opposed. Ship first, ask questions later, or, move fast and break things, wins.

  • Here I go again: Plan9 had per-process namespaces in 1995. The namespace for any process could be manipulated to see (or not see) any parts of the machine that you wanted or needed.

    I really wish people had paid more attention to that operating system.

    • The tooling for that exists today in Linux, and it is fairly easy to use with podman etc.

      K8s choices clouds that a little, but for vscode completions as an example, I have a pod, that systemd launches on request that starts it.

      I have nginx receive the socket from systemd, and it communicates to llama.cpp through a socket on a shared volume. As nginx inherits the socket from systemd it does have internet access either.

      If I need a new model I just download it to a shared volume.

      Llama.cpp has now internet access at all, and is usable on an old 7700k + 1080ti.

      People thinking that the k8s concept of a pod, with shared UTC, net, and IPC namespaces is all a pod can be confuses the issue.

      The same unshare command that runc uses is very similar to how clone() drops the parent’s IPC etc…

      I should probably spin up a blog on how to do this as I think it is the way forward even for long lived services.

      The information is out there but scattered.

      If it is something people would find useful please leave a comment.

      1 reply →

  • ...but the github runners already are virtualized; you'd need to virtualize the secrets they have access to instead.

The lesson surely though is 'don't use web-tech, aimed at solving browser incompatibility issues for local scripting'.

When you're running NPM tooling you're running libraries primarily built for those problems, hence the torrent of otherwise unnecessary complexity of polyfills, that happen to be running on a JS engine that doesn't get a browser attached to it.

Same story from a month ago. The moment I saw the sheer number of dependencies artillery wanted to pull I gave up.

I used to run npm only inside docker containers, and I've been regularly laughed at on these forums. I eventually gave up…

  • “Whenever you find yourself on the side of the majority, it is time to pause and reflect." — Mark Twain (supposedly)

It's funny because techies love to tell people that common sense is the best antivirus, don't click suspicious links, etc. only to download and execute a laundry list of unvetted dependencies with a keystroke.