Rebuild TemplateVM with updated signing key

[eloquence]

As part of the planned keyring rotation (freedomofpress/securedrop#5923), we need to update the signing key used in this template to the new key and fingerprint, and build an updated template.

Sub-tasks

• Resolve dual keyring problems (requires updates to build script) - Docs and builder updates #21
• Update documentation for template build procedures - Docs and builder updates #21
• Add a prod-signed tag on HEAD of main post-merge of changes above - https://github.com/freedomofpress/qubes-template-securedrop-workstation/releases/tag/0.2.3
• Build new TemplateVM RPM, save build logs: add workstation template 0.2.3 securedrop-yum-test#26
• Sanity check the new RPM via manual installation and testing
• Sign that RPM with the test key, upload to yum-test (via https://github.com/freedomofpress/securedrop-workstation-dev-rpm-packages-lfs/) , and post build logs
• Perform clean install in staging environment, via yum-test, confirm client functionality
• Update the keyring tests in https://github.com/freedomofpress/securedrop-workstation/blob/46054d1607f863f24d4ebf6504681b44f83ee09f/tests/test_vms_platform.py#L120
• Promote RPM to prod and resign with new prod key - Adds SDW buster template rpm 0.2.3 securedrop-yum-prod#20

[conorsch]

freedomofpress/securedrop-builder#250 has been merged, but the packages aren't live yet. We'll need to have securedrop-keyring=0.1.5 served in the prod apt repo in order to rebuild the template as described here.

[conorsch]

Taking a look at this today. We now have the 0.1.5 keyring package available in prod: https://apt.freedom.press/pool/main/s/securedrop-keyring/securedrop-keyring_0.1.5%2Bbuster_all.deb

In order to make a build, we'll need a prod-signed tag on this repo. I plan to create one of those, but first, I'll simply test the build logic, using the 0.2.2 tag from 2020-07. There are two more recent test-only tags:

• https://github.com/freedomofpress/qubes-template-securedrop-workstation/releases/tag/20210519-test
• https://github.com/freedomofpress/qubes-template-securedrop-workstation/releases/tag/20210520-test

which I may delete as part of this work. Or, I can push an individually-signed tag on top, as long as it points to the most recent commit on main branch.

[conorsch]

Dug up some notes by @emkll in internal chat, posting here for posterity:

---

Earlier today I managed to build a dom0 template using the existing logic, but there was a small issue with the keyring that will require an update to the build-workstation-template script. I confirmed the template build is working with Fedora 33, though requires a manual step 🎉

I have created a branch in https://github.com/freedomofpress/qubes-template-securedrop-workstation/tree/test-build updating the signature to my personal signing subkey (not the main fingerprint ID) and pushed a corresponding test tag in https://github.com/freedomofpress/qubes-template-securedrop-workstation/releases/tag/20210520-test

The (signed) tag must point to the last commit on the branch, and logic should change to include the new key (and have the next "production" tag be the new signing key FP. Once the securedrop-keyring package is updated, you can rebuild the template. make template will fail early on, because for some reason, there's a keyring for the qubes builder, and a keyring for template-securedrop-workstation (I am not sure why, this is new and requires investigation).

After the make template failure, i just followed the commands that were in the build-workstation-template to add and trust my primary public key:

echo "AF775782949D263DAABB3387AAFB3575FAC82745:6:" | gpg --homedir qubes-builder/keyrings/git/template-securedrop-workstation/ --import-ownertrust

After running the other commands manually:

make get-sources
make install-deps
make qubes-vm
make template

The template should be successfully built in qubes-builder/qubes-src/linux-template-builder/rpm/noarch

[conorsch]

Was able to build a new RPM today. The comments above on the keyring changes were extremely helpful. Pushed WIP here: https://github.com/freedomofpress/qubes-template-securedrop-workstation/tree/test-build-keyring For now, preserved separate changes in https://github.com/freedomofpress/qubes-template-securedrop-workstation/tree/test-build, since a signed tag is required as part of the build logic.

Next steps:

• updating the docs to be a bit more explicit about the relevant procedures (stressing the need for a signed tag on the HEAD of the target branch)
• patch the build-workstation-template script to handle the component keyring, now required by the upstream qubes-builder logic (the Qubes keyring and the qubes-template-securedrop-workstation keyrings are now handled separately)
• pair with @creviera on review of the above
• once all PRs are merged, tag latest main and build a prod-ready RPM. we'll post to yum-test first for more testing

[conorsch]

Pushed a prod-signed tag: https://github.com/freedomofpress/qubes-template-securedrop-workstation/releases/tag/0.2.3 Note that this is signed with the current/old key, i.e. 22245C81E3BAEB4138B36061310F561200F4AD77. The tag will still verify up until the expiry date of 2021-06-30, so it's suitable for immediate rebuild of the template. Once we have an RPM available on yum-test, and later promoted to prod, we can circle back to update the template yet again, removing the expired key, and retag with the new key.

[conorsch]

Post-merge of freedomofpress/securedrop-yum-test#26, I attempted to:

Perform clean install in staging environment, via yum-test, confirm client functionality

and unfortunately ran into problems. While the provisioning completed, and the updater ran without error, DispVMs would fail to open applications. I tested at last JPEG and XLSX files, same behavior: DispVM starts, no window is drawn, DispVM halts. These are the steps I used to configure the staging install:

1. sdw-admin --uninstall --force to remove any previous setup
2. reboot
3. download https://yum.securedrop.org/workstation/dom0/f25/securedrop-workstation-dom0-config-0.5.4-1.fc25.noarch.rpm in domU, ferry to dom0
4. sudo dnf install -y <rpm>
5. Confirm that /usr/share/securedrop-workstation-dom0-config has enviroment: "json"
6. sdw-admin --apply
7. Reboot
8. Run GUI updater
9. Log into client
10. Download and open a submission, observe failure

I haven't spent any time investigating the nature of the failure, so I'll start on that now. I did perform two full runs of the above test plan, and the results were the same each time. @creviera could you try to reproduce this behavior, following the steps above?

[conorsch]

Returned to this step today:

Perform clean install in staging environment, via yum-test, confirm client functionality

And I'm pleased to report positive results. The concerns raised yesterday around DispVM breakage were addressed separately in #705, and we've confirmed that those observations were unrelated to the new template being tested. Marking that step as complete, and I'll prepare a prod-signed artifact for yum.securedrop.org.

[eloquence]

@creviera will aim to work on the remaining task during this sprint:

Update the keyring tests in https://github.com/freedomofpress/securedrop-workstation/blob/46054d1607f863f24d4ebf6504681b44f83ee09f/tests/test_vms_platform.py#L120

[eloquence]

This work was completed in freedomofpress/securedrop-workstation#715