[exec1]

Fair enough. I have clarified my use case at the top of my article to reflect my threat model. I don’t use the VM to run tricksy software I don’t trust so the sandboxing argument doesn’t really apply in my case (or rather it doesn’t apply any more than when running software directly on the host). All of the software I run on my VMs is the same software I would run on my host (if the host was Linux-based).

[chromakode]

Likewise, fair enough. I appreciate you clarifying your threat model. I try to operate with low trust dev environments whenever possible, which is a major motivation for using VMs. It only takes one malicious npm or pip package for it to pay off.

[exec1]

Yeah, I hear you. I try to avoid pulling NPM packages that I don’t know so I’m not really interested in containing software for security purposes.

Of course, there’s also the question of dependencies. If I’m working on a project that I trust that pulls in hundreds of NPM dependencies, I implicitly trust that the project deemed those dependencies safe to pull in. It would be impossible to always operate on the assumption that you’re potentially pulling in hundreds of malicious packages so the chain of trust has to take over at some point.

However, I imagine you were more or less referring to singular projects that you don’t fully trust and like to experiment with in which case I agree with you and would probably use a VM without any kind of file sharing tbh.