Docs and builder updates #21
Conversation
The qubes-builder logic now uses a separate keyring for "template-securedrop-workstation", so we'll add the signing key for verifying SDW tags to that separate keyring. Since we're in the middle of a key-rotation process, let's make sure to add both the old and new signing keys, as well.
We typically revisit this logic once or twice a year, which means the build scripts and even the docs can get out of date fairly quickly. Adding more detail with an eye toward explaining the implicit assumptions about how the logic works.
| 1. Create a fedora-31 based AppVM for building the templates | ||
| 2. Increase the disk size to at least 20GB (as the build uses over 10GB): qvm-volume extend sd-template-builder:private 15GB (if your VM is not named sd-template-builder, adjust that command) | ||
| 3. Import the QubesOS master key and the GPG key used to sign tags (see https://www.qubes-os.org/security/verifying-signatures/) | ||
| Set up a long-lived VM that you can use for building SDW templates. |
There was a problem hiding this comment.
should we mention whether or not the vm you set up here should be separate from the dev vm you set up to build workstation components?
README.md
Outdated
| 3. Import the QubesOS master key and the GPG key used to sign tags (see https://www.qubes-os.org/security/verifying-signatures/) | ||
| Set up a long-lived VM that you can use for building SDW templates. | ||
| You'll only need to perform this step once, although make sure to check | ||
| whether your Fedora version remains current. |
There was a problem hiding this comment.
i think the "although make sure to check whether your Fedora version remains current" could be a 4th step below or part of something you do before you make the template. We might want to say how to ensure your new AppVM is current before using it by running sudo dnf upgrade
| ``` | ||
|
|
||
| ## Acknowledgments | ||
| This work was inspired by and reuses code from the Whonix Qubes template: https://github.com/adrelanos/qubes-template-whonix |
There was a problem hiding this comment.
+1 to moving this to an acknowledgements section
README.md
Outdated
| You'll only need to perform this step once, although make sure to check | ||
| whether your Fedora version remains current. | ||
|
|
||
| 1. Create an AppVM based on the most recent fedora release: `qvm-create --label purple --template fedora-33 sd-template-builder` |
There was a problem hiding this comment.
recommend changing fedora-33 to fedora-XX where XX is the latest version of fedora available (which you can see within the Qubes menu)
There was a problem hiding this comment.
I was able to build the rpm successfully following your test plan and the updated readme. The comments in the PR review are more questions/ ideas -- not blockers, so I will approve so you can decide if you want to make any more updates or merge so you can move on to kicking off a real build
| 1. Repace the following value in `securedrop-workstation.conf`: ` BRANCH_template_securedrop_workstation ?= $TEST_BRANCH` | ||
| 2. Sign the tag using a trusted key (or edit the `builder/build-workstation-template` script to import/trust the key) | ||
| 3. `make template` | ||
| The qubes-builder logic expects signed tags on the most recent HEAD commit of the target branch. |
There was a problem hiding this comment.
it wouldn't hurt to mention one more time that the qubes-builder expects this singed tag to be pushed to remote (it's mentioned below but it's an important enough detail to mention here too i think)
|
Great feedback, @creviera! I'll make a few line edits as you suggest, then proceed with merge. I've added a checklist to the associated issue (#20) tracking the next steps, we can start plunking through that process together. |
Based on feedback by @creviera during review. Trying to make it crystal clear what the likely stumbling blocks are.
|
Docs changes in place. On a final visual review locally, I realized that there's still another place where the key material should be updated: I'm going to follow up with another small PR addressing that change, to aid in review. |
Two changes here:
Testing
make templateThe goal of the review is simply to emit an RPM for the TemplateVM (and ideally test that in dom0). Actually building a prod-ready artifact is out of scope for this issue, we'll follow up with a signed tag and build again post-merge, in order to satisfy #20.
Give that a whirl, and let me know if anything is unclear!