deploy: install template-from-qubesdb in base template and sd-whonix

[cfm]

Status

Ready for review

Description of Changes

• Closes provide reusable script for rendering templates from QubesDB variables #1039 by adapting freedomofpress/securedrop-client@27cc69d into template-from-qubesdb.py, which is installed directly into the base template and sd-whonix so that it's available without requiring the installation of a separate package. (This approach is up for debate!)
• Closes [4.2] Write vm-specific config values to qubesdb #936, of which this is the final non-secret-provisioning part.

Follow-up work

• Set logvm via vm-config #1029

• securedrop-workstation/dom0/sd-whonix.sls

  Line 47 in a106e93

  # TODO: sd-whonix:/var/lib/tor/keys/app_journalist.auth_private

Testing

1. Delete all your sd-* VMs so that sd-{large,small}-bookworm-templates can be recreated

2. make clone && make dev

3. In sd-whonix, create and test a template, e.g.:

   [gateway user ~] % cat > template <<EOF
   > {"hidserv_hostname": "$SD_HIDSERV_HOSTNAME"}
   > EOF
   [gateway user ~] % template-from-qubesdb template newfile

4. newfile contains the value of qubesdb-read /vm-config/SD_HIDSERV_HOSTNAME.

Checklist

If you have made changes to the provisioning logic

• All tests (make test) pass in dom0

No tests are required here, but they will be for the "Follow-Up Tasks" listed above.

If you have added or removed files

• I have updated MANIFEST.in and rpm-build/SPECS/securedrop-workstation-dom0-config.spec

[legoktm]

which is installed directly into the base template and sd-whonix so that it's available without requiring the installation of a separate package. (This approach is up for debate!)

Since it's going in a template/VM, I think it should be in a package. Also we'll presumably want a oneshot systemd command to generate the file on VM startup, so that'll also benefit from being packaged?

I think creating a new securedrop-qubesdb package would be pretty lightweight (or securedrop-whonix-config or ...) if it's just installing one Python file, the config template and a systemd service.

[legoktm]

The downside is that we'll need to install the securedrop-keyring package in the whonix template :/

[cfm]

Yes, exactly. I've been thinking about this mechanism as a concession to the reality that we will want to configure third-party things = things not from our packages = things not necessarily on top of our base template. So consider this a straw man for the purpose of testing that hypothesis—let's discuss further.

[cfm]

@legoktm and I have discussed the tradeoff between (a) directly injecting this script (as proposed here) versus (b) packaging it. The new plan of action is to:

1. move this script back to securedrop-client;
2. package it as securedrop-qubesdb; and
3. create a package that depends on securedrop-qubesdb for each VM or feature that needs QubesDB configuration (e.g., Set logvm via vm-config #1029) to set up a one-shot systemd timer to configure itself using this script.