IDEs, plugins, development utilities, language libraries, OS packages, etc. So much code that I take on blind faith.
Several years ago I worked somewhere that prohibited web browsers and development tools on laptops. If you needed to use a browser, you’d have to use one over Citrix. If you needed to code, you’d use a VDI or run the tools in a VM.
At the time I thought their approach was clinically insane, but I’m slowly starting to appreciate it.
Except the vm is some old windows version without any tools on it. no shell access.
can't actually do anything useful on there at all.
VDI systems could work if implemented properly. but that's the last thing a security team actually wants to do.
On our laptops, there are still some flows that avoid the vpn etc..
A hybrid(?) alternative is enroot, which is pretty neat IMO, it converts a docker container into a squashfs file that can be mounted rw or used in an ephemeral way. https://github.com/NVIDIA/enroot
A newer project fires up VMs from a Python script that calls an adapter for EC2 (with the boto library) when run on AWs and for VirtualBox (by calling VBoxManage) when running locally. That allows us to simulate EC2 locally: it's a project that has to deal with many long jobs so we start VMs for them and terminate the VMs when the jobs are done. That also runs better on our mix of development systems. WSL2 helped to ease the pains of developing on Windows. We call the native Windows VirtualBox, not the one we could have installed inside WSL2, but we keep most of the code that runs on Linux.
Unlike with Terraform/OpenBao, I know of no community effort effort to keep the open-source version of this project alive. The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs.
The license change is irrelevant - from the licensing page:
> All non-production uses are permitted.
Devs who use Vagrant in a development environment can do it as they used to do it before.
> The latest open source version is still available on the Ubuntu repo, but who knows who long it will work until somefor of bit rot occurs.
Hashicorp products have always been intended to be downloaded from the website, since they're statically linked binaries (I don't like that they're huge, but matter of factually, they make distribution trivial).
None of my jobs since have had any semblance of a better way to set up a local dev environment easily.
It was just way easier to encapsulate services or other things in a quickly reproducible state.
I digress..
There's also a thread for Zed about a path to implementing it there [0]. Hopefully it'll become a bit more common over 2025.
Works well with Homebrew, and copies all the config files that devs often don't set up.
Let’s be clear, it’s still clinically insane, even if marginally rationalized.
nvidia gates it's virtualized GPU offerings behind their enterprise cards, so we're left with ineffective command translation.
IMO: I can tolerate just about every other type of VM overhead, but choppy/unresponsive GUIs have a surprisingly bad ergonomic effect (and somehow leak into the performance of everything else).
If we could get that fixed, at least amongst Linux-on-Linux virtualization, I think virtualizing everything would be a much more tenable option.
If you can't do that because it's for company/corporate purposes then I can sympathise with not wanting to pay Nvidia's prices.
> Using Remote-SSH opens a connection between your local machine and the remote. Only use Remote-SSH to connect to secure remote machines that you trust and that are owned by a party whom you trust. A compromised remote could use the VS Code Remote connection to execute code on your local machine.
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
If you're worried about extensions there's also:
> When a user installs an extension, VS Code automatically installs it to the correct location based on its kind. If an extension can run as either kind, VS Code will attempt to choose the optimal one for the situation;
https://code.visualstudio.com/api/advanced-topics/remote-ext...
Specifically I'm transitioning my Go and Zig development environments from an old mac to an M1 with Asahi Linux and getting a bit lost even finding replacements for Truecrypt and Little Snitch. Do these VM tools support encrypted VM's with firewall rules? I saw Vagrant mentioned here and that sounds like it might cover the network isolation, but what else would you suggest?
LXD, unlike Docker, doesn't play fast-and-loose with security. It runs rootless by default, and I don't allow non-root access to the LXD socket on host. Each container is a full userspace, so it's much more convenient to configure and use than Dockerfiles.
SSH from a container to a remote works transparently because I forward my SSH Agent. This is secure because my agent confirms each signing request with a GUI popup (on host).
Part of the appeals of VMs is that they were built with security as a primary objective. I probably have to do something stupid to break that isolation. A custom ad hoc configuration makes me a bit nervous that I will unknowingly punch a Docker sized hole through my firewall and have less security than if I ran a stock workflow.
If you go this route, create a container template that has everything you want in every instance. And then spin out new containers whenever you need one.
These days I work in JavaScript and rarely have issues with project environments interfering with each other. I've gotten lazy and don't use VMs anymore.
In theory docker type setups could work but they just seem so much effort to learn and setup.
Basically I put a Vagrantfile in src folder, then run docker compose with db, caddy, app server and other services inside it - then I forward ports 80 and 443 from vm and use localhost.whateverdomain.igot with self-signed cert on caddy (since https is just enough different than http that I otherwise get bitten by bugs every so often).
When I start a new project I can usually just copy the Vagrantfile with minimal changes.
The VM might protect me, but it will not protect the users of the software I am producing. How can I ship a product to the customer and expect them to safely use it without protection when I myself only touch it when in a hazmat suit?
No, that is not the environment I want.
My current solution is to be super picky with my dependencies. More specifically I hold the opinion that we should neither trust projects nor companies but only people. This is not easy to do, but I do not see a better alternative as for now.
i've got a simple per-project dot file that describes the file system binds. while i'm working on a project, new terminals i open are automatically isolated to that project based on that dot file. it has very low (cognitive) overhead and integrates pretty much seamlessly. i suspect many developers have similar scripts. i looked for projects that did this some time ago, but couldn't find it. either because it's too simple to make a project about, or because i don't know how others would describe it. if anyone has pointers...
i don't limit network access (though i did experiment with logging all traffic, and automatically setting up a mitm proxy for all traffic; it wasn't convenient enough to use as regular user). there is still a whole kernel attack surface of course. though i'm mostly concerned about files being read/destroyed.
If you ran a key logger on my machine you would never get into any major site with mfa. You couldn't watch me log on to the azure console with passkey and do much with it. But if you scrape a saved key with publish abilities bad things happen.
I did not start doing this because of security, but just to get something more or less self managed without any possibility to break different projects. I am tired of my team spending too much time on extensions, versions, packages, ...
Docker compose files have saved our team many hours, even if it's extremely wasteful to have multiple vscode instances running alongside each other
For work use I use a work machine and if it gets compromised it's not really my own problem.
Is that really a good mindset for a organization?
It's not up to me to decide what policy to use, and if it was I couldn't just do whatever I wanted, I'd have to justify its cost. And every company does the same…
I can decide the policy at my home :)
It doesn't fully sort out the trust issue though, even if everything is sandboxed in some fashion.
All the stuff using Android intents, out-proc COM extensions in Windows, XPS in macOS, are other relevant set of examples.
I assume you are kind of new to the computing world, OS IPC is how we extended applications almost 40 years before shared libraries became common feature across all major operating systems.
Naturally with them being around, shared memory in-process was much easier, and less resource intensive. IPC calls require processes, which take more kernel resources, and context switch.
Microservices isn't a new concept, rather re-branding.
Sun had as marketing quote, "The network is the computer", exactly because of how it used to be.
Also, many people here work on multiple projects for different customers. Having a security breach for one affecting the other is not something you'd be happy with.