Discussion: can we deprecate or simplify securedrop-handle-upgrade?

[rocodes]

• I have searched for duplicates or related issues

Description

We have a script, securedrop-handle-upgrade, that is invoked via Salt in sd-upgrade-templates.sls. Its main purpose is to make sure that base templates for vms (debian, whonix) are correctly up to date for a given VM (for example, migrating a major OS version and switching templates). Its secondary purpose, via remove, is to clean up old sd templates after an upgrade.

As the script mentions, to update an appvm's template, the vm must be a) powered off, and b) not be appvm template for a disposable VM that is either the default disposable or the system disposable.

The downsides of this approach are:

• it's convoluted (Salt requsite -> salt state that invokes a script with a defined arg -> script shells out to "qvm" commands, but we're already in the middle of a salt run...)
• it is applied both in the dom0 top file, but also (inconsistently) as a requisite in some but not all appvms (eg: it's a requisite in sd-gpg.sls but not sd-app.sls or sd-viewer.sls).

It might be better to move this out of a script and into the individual vm configuration. Afaict we can use qvm.vm to ensure that the VM's state is "powered off" (goal 1), and use "prefs" for the VM to ensure that it has the correct template (goal 2).

The original goal of the script was that if a user missed a dom0 update where the template migration took place, they could still successfully upgrade (particularly during template consolidation). But I think we can deprecate this, at least at the individual vm level. Would like a second opinion though (@deeplow @legoktm maybe ?)

How will this impact SecureDrop/SecureDrop Workstation users?

Should be no-op; potentially faster provisioning

How would this affect the SecureDrop Workstation threat model?

Should be no-op

User Stories

(n/a - developer quality of life/ease of maintenance)

[legoktm]

It's been a while since I looked at that script, I have no attachment to it and would go on my normal spiel about how that complex logic doesn't belong in bash scripts, etc. :), so I'm down to move it to salt.

[deeplow]

I'd be happy to see securedrop-handle-upgrade go away. But I'd like to brainstorm a bit about the various approaches. Off the top of my mind I can see a few:

• Move these to our salt states - I'm not very fond of this idea because breaks something simple like qvm.prefs vmname template=... into three logic blocks: check if template upgrade needed + shutdown if so + change template. We'd have to do this for every VM that needs template changes or we go in the jinja templating direction which makes the code harder to reason about. But it would be an improvement over the status quo and quite pragmatic.
• Shouldn't Qubes Support this? ideally we'd just state the template we want in salt and and it handles the necessary shutdowns instead of simply refusing. I think from SaltStack if should be an acceptable tradeoff to be forceful on actions. So it should just be a matter of adding an if clause for templates similar to this one and do there the appropriate shutdowns.
• Health check - I can't find the ticket, but we had the idea of health monitoring - a simple check if things are in order when running the updater. Running the health checker could know that templates are not as expected and run the full salt states.

With that said, I'd like to think a bit more about this. The above are just initial ideas on how to tackle this problem. But in general I'd love for the provisioning tool to be something that we simply say what exists and things happen in the background without us needing to think too much about how to achieve that.

Lastly, I think tackling this eventually feels like a good opportunity to decouple system VM management from SecureDrop "MultiVM Application" logic, although our use of Whonix is a bit mixed in that regard.