Consider preferring Salt customizations to custom template RPM

[conorsch]

We've long maintained a custom RPM leveraging the qubes-builder logic to install the base image for SDW: https://github.com/freedomofpress/qubes-template-securedrop-workstation. In the process of managing the Debian Bullseye migration (#733), we've updated the template builder logic as per usual: freedomofpress/qubes-template-securedrop-workstation#24 This is a fine plan, and we should stay on target to meet the EOL deadlines.

When it comes time to move to Debian 12, however, we should consider whether it's worthwhile to maintain custom RPMs for the TemplateVM images. Given that we already qvm-clone the base template into "small" and "large" variants, we could do the same via Salt targeting the qubes-template-debian-12 base image. Why not just use the existing debian-12 image already installed? Let's discuss that before the next migration.

[rocodes]

Just bumping this and adding some context on our use of the custom template:

• We ship the SD release key file, fingerprint, and sdw apt repo configuration. (The key file is just used initially, to set up the FPF apt repo, after which the keyring package manages the template's key rotation).
• We install the securedrop-relevant packages (securedrop-workstation-grsec, securedrop-workstation-config, securedrop-keyring), as well as some debian packages (apt-transport-https, qubes-vm-recommends, although the latter is an older workaround that may now be able to be deprecated)
• We make some modifications in the postinst script, such as removing ntpupdate

It does seem like https://github.com/fepitre/qubes-builderv2 is in a pretty polished state, so maybe creating a builder.conf file and building templates will be less complex and evolving than it has been in the past. But since this has been time-consuming I think it's worth discussing whether we have to ship a template or whether there's another way we're happy with to do that initial bootstrapping.

[cfm]

Some intuitions, subject to my usual straw-person-for-the-sake-of-argument disclaimer:

• Reality check: Do we have threat-modeled reasons for wanting to ship a downloadable template rather than clone and configure it locally? (The threat-modeling discussion in securedrop-workstation's readme does not suggest any.) If we do, then we should reevaluate those as part of this discussion. If we don't, then...
• Principle: However we feel about Salt, maintaining two configuration-management schemes (Qubes Builder + Salt) is more technical and process work than maintaining one (Salt). (Whatever we might offload configuration-management work to from Salt could also pick up this provisioning.)
• Hypothesis: Downloading a custom template is generally slower than cloning a stock template and configuring it (which we do anyway).
• Hypothesis: Cloning a stock template and configuring it is not more fragile or error-prone than downloading a custom template (and then cloning it and configuring it some more).

Unless we can come up with a clear advantage to maintaining and installing a custom template, I would much prefer that securedrop-workstation-dom0-config be the only artifact we produce for dom0. (I'm setting aside the .repo file and the release key in the work VM, since they are strict prerequisites for downloading and verifying that artifact.)

[cfm]

@rocodes, here are my takeaways on this topic from discussion with @marmarek today:

• @zenmonkeykstop mentioned one reason for a custom template that we haven't yet captured here: What if a user installing the Workstation on a non-fresh Qubes system has made changes to their base debian-12 template? This is a justification for cloning from a known-good template, which Qubes doesn't currently have any mechanism for checking or ensuring. It isn't (by itself) a justification for building, releasing, and downloading the particular custom template we currently have.
• qubes-builderv2 is absolutely stable and intended for third-party use. Whonix has adopted it, and we can learn from their approach as this repository learned from their use of the original qubes-builder.
• Requests for new things or changes we'd like to see are always welcome.

[zenmonkeykstop]

I haven't looked at the threat model to see if that last point is there, but it could be a valid candidate for a "transfer" mitigation if we did wanna use the debian base template, basically documenting the requirement for a fresh system with no template customizations, and leaving it to users to do the right thing. Being able to detect chnages in the template (beyond system updates) would be ideal tho.

[rocodes]

Per team meeting, we are going forward with the approach of cloning the existing Debian template that Qubes provides, rather than continuing to ship our own VM, for our 4.2 compat release.
Our rationale is that SDW is expected to be provisioned in a fresh-installed Qubes environment, a requirement we'll continue to make explicit, without previous modifications of the existing Debian template, so we're ok with cloning the template and applying our changes (basically adding our signing key and apt repo) on top of that.

[zenmonkeykstop]

Basic steps for this during the install would probably look like:

• install debian-12-minimal (if it's already present, do nothing, we're assuming the Qubes install is sdw-only)
• clone securedrop-bookworm-trusted-template (for sd-app, sd-log, sd-proxy, sd-gpg)
  • do similar setup steps to those in https://github.com/freedomofpress/qubes-template-securedrop-workstation/blob/main/securedrop-workstation/04_install_qubes_post.sh to add our key, repo, and base packages (grsec etc)
  • install relevant application packages similar to those in securedrop-buster-small-template
• clone securedrop-bookworm-untrusted-template (for sd-viewer, sd-devices)
  • do similar setup steps to those in https://github.com/freedomofpress/qubes-template-securedrop-workstation/blob/main/securedrop-workstation/04_install_qubes_post.sh to add our key, repo, and base packages (grsec etc)
  • install relevant application packages similar to those in securedrop-buster-large-template

Alternatively we could create a single base template, similar to the one we have now except at install time, and then clone small/large from it. Might be conceptually similar.

[rocodes]

Fixed via #970