For software engineers using Qubes as their primary work machine, what have you found to be your most productive workflow with Qubes? Is your workflow/setup informed by any particular threat model?
For the last year or so I’ve just been using standalone VMs for all my dev work. I’ve accumulated a lot of kruft between my opensource contribution vms and work vms running this way. Tons of duplicated docker images, repos, libraries, etc.
I was recently inspired by @unman 's shaker repo and others to setup sys-docker/sys-git/sys-go type vms to centralize/dedupe containers/repos/libraries and access offline over rpc. Is anyone actually using a setup like this, and if so, have you gotten any value out of it? This has been fun, so I’m worrying that I’m just procrastinating with a new toy and not actually improving anything.
For context I’m writing software in C, Go, Typescript/JS, Lua, and Hoon. Linux has been my daily driver since the late 90s. I have no expertise in salt, but it’s been really easy to pick up from prior art here (thanks @unman, @prago and others!) and I’m using it to manage most of my VMs. So while I’m pretty green with QubesOS, I’m down to get into the weeds to get things dialed in.
In terms of threat models, now that I have to dip into Javascript/Node.js land, supply chain attacks are one of my bigger concerns. I’ve got some pretty gnarly layouts in mind (dev-dvm → snyk-like-dep-vetting-proxy → sys-net-ids), but I may be going a little overboard.
I use yubikeys as PGP smartcards for encrypt/sign/ssh, so I haven’t really taken advantage of splitgpg/splitssh.
Qubes blows all other options out of the water for edge/non-cloud development.
I tend to use template based offline (none for NetVM) AppVMs for development and, template driven DispVMs for debugging/testing/reversing (mostly offline & locally networked to other test qubes, rarely online but, happy with the threat model since they are DispVMs).
While I recognize the value of rolling out SaltStack solutions to align with Qubes purists (and to learn something new). I haven’t found a simple way to “stack” the salt shakers. Thus, what’s been working well for me currently is using Ansible Qubes [many thanks to @Rudd-O ] for DevOps.
Typical workflow:
Spec out a base template and an associated Disposable template AppVM
Write playbook for desired application/SDK/tool
Deploy said playbook
Test said system for desired functionality
This seems to be where the most time spent is as, software installs like to do their own thing these days (even with configuration constraints applied [yes, I’m talking about NVM and the like which have decided to stuff things into /home and other locations not inherited by AppVMs]).
Bind-dirs can do the job
Really ought be leveraging nix-env for package management to avoid the hassle of chasing down the odd places some stuff gets installed which doesn’t always play nice with Qubes inheritance.
Once I know I’ve got a playbook that gives me what I’m after, I’m able to remove the singular app based Template/AppVMs
Now that the sauce is canned, I’m able to:
Clone a TemplateVM of choice to something like super-secret-dev
Mix & match playbooks to deploy to super-secret-dev, effectively making the “stew”-of-the-day
Make AppVM/DispVMs as necessary.
Hope this helps.
Re NVM: I found it to be less DevOps friendly than I would like; have since replaced with fnm.
Thank you. I have also created shims that can be used as fake “ssh” for salt-ssh users:
These days I’m mostly using SaltStack because it lets me do interesting things at faster speeds. The initial “log into machine and deploy the playbook” part is slow, but once it’s executing, it’s way faster than Ansible.
