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.