Release SecureDrop Workstation 1.1.0

[rocodes]

This is a planning ticket designed to lay out what will be required to release SecureDrop Workstation 1.1.0, with support for a new securedrop-workstation-keyring package.

Pre-release tasks

• Merge remaining workstation-kerying PRs: Add rpm import in %post securedrop-workstation-keyring#4
• Add basic keyring sanity test (python) securedrop-workstation-keyring#8 (WIP: Add smoketest (package installed, keyring/repo files in place) securedrop-workstation-keyring#9)
• Ensure workstation-keyring package is compliant with qubes-builder expectations
• Decide securedrop-workstation rpm dependency on workstation-keyring package (Requires?)
• Release securedrop-workstation-keyring (first to yum-test, then to yum repo; requires infra support; requires version number decision)
• Decide on dev/staging provisioning strategy compatible with securedrop-workstation-keyring #1232
• Update workstation-ci-runner to pull in workstation-keyring package for CI runs
• Review and merge remaining securedrop-workstation PRs (ready now): Set vm template consistently across Salt files; cleanup unused requisites #1226, Bump supported fedora version to 41 #1221, Use qvm.anon-whonix, deprecate securedrop-handle-upgrade for sys-whonix #1227
• Review and merge remaining securedrop-workstation PRs (dependent on keyring package being available): WIP: Configure dom0 rpm repo settings via boostrap rpm package. #1210 Make grub2-xen-pvh a dependency of dom0 config rpm #1211
• Create workstation docs PR with new dom0 rpm instructions
• Submit package to qubes-contrib (does not need to be live on qubes-contrib for release, assuming we are also publishing)

Release tasks

• Assign roles
• rc version + changelog bump
• packages on yum-test; qa
• Prod version bump, changelog, and signed tag
• Prod QA (yum-qa)
• Prod release
• Update docs tag

Post-release tasks

• Followup qubes-contrib review as needed
• Bump version on main

Test Plan

Fresh install

TK

Upgrade testing

TK

[deeplow]

We may want to do this one in coordination with https://github.com/freedomofpress/securedrop-client/milestone/14, since diverless printing support will require adding the avahi qubes service.

[legoktm]

Are there any concerns/issues if we enable the avahi service ahead of time?

[deeplow]

It's just just that the way we go about setting Qubes services is via salt. So we need to do a workstaiton release. We can do an individual one just for that. But I was thinking that since this one is pretty small, they could be combined to avoid having the users run two "migrations".

[rocodes]

@deeplow is the driverless printing workflow finalized, even if the code is not?

If the services we need to enable are known/finalized, I see no issue with merging a PR that adds that functionality and including it in this release, particularly if we have a timeline for the corresponding client release. If there is any question about which services will be needed (just avahi? cups-browsed? avahi-utils?), or if the corresponding client release timeline is still a ways off, we may want to wait and release the printing specific changes all together, since it's pretty painless to build and release an rpm now, especially one that won't need much manual QA. What do you think?

[deeplow]

@deeplow is the driverless printing workflow finalized, even if the code is not?

I think the workflow is pretty much the same as we have now. So I would be inclined to say yes.

[...] If there is any question about which services will be needed (just avahi? cups-browsed? avahi-utils?),

From my testing we just need to add the avahi service. The cups one was already there.

Since it's pretty painless to build and release an rpm now, especially one that won't need much manual QA. What do you think?

The main thing I was thinking about was the need to run a salt "migration" - i.e. extra time for users the updater w/ salt twice where we could bundle it in one. But what we could do is already add the avahi service in the workstation 1.1.0 release, and do some light testing if printing doesn't break. And later for the client we can just simply do it via a regular client release with the path unblocked thanks to the already present service. But we could also find in printing QA that something else is missing so I cannot 100% confirm this is all we need.

[rocodes]

Hey, thanks for the followup :)

I think the workflow is pretty much the same as we have now. So I would be inclined to say yes.

Ah, perhaps "workflow" was a bad choice of words on my part, but what I mean is there are differences: which services need to be enabled, which additional packages need to be installed, etc. (To know this, we need rudimentary working driverless print instructions for a deb-minimal vm with a grsec kernel, even if they are just a series of manual commandline instructions in a gist that explain which services were enabled, which packages were installed, and which commands were used to set up the printer).

we could also find in printing QA that something else is missing so I cannot 100% confirm this is all we need

istm this part should be the first thing that's solid, even if it's a series of manual steps/instructions, and we should have some certainty around the manual steps before we move on to implementing/automating? I don't want to get into a rabbithole, but if that's not the case I think we should make sure that's a known quantity before we ship any changes in dom0, and maybe follow up on that in freedomofpress/securedrop-client#2088 or wherever is the right place.

[rocodes]

(I agree that if we are already doing a full salt run to update VM templates, it's a good time to make other small changes like enabling services we know we'll need, etc, so I would say as long as we have clarity around that, there's no issue with including additional small configuration changes at the same time, if they've been tested/confirmed to be the implementation path we plan to take.)

[deeplow]

Sounds good. I think it's just a matter of adding the avahi service. Everything is a matter of configuration, which we can do in a later release. That's a requirement if we want driverless printing. But we can discuss specific in the specific issue.

[rocodes]

To update: I checked in with @deeplow about the status of client/print stuff. Based on that check-in, my understanding is that the changes to VMs/templates that are required to support driverless printing are already decided. If that's the case, I think a workstation PR can be merged whenever the time is right, especially if it's just enabling the avahi service in sd-devices plus a couple extra vm tests.