Release SecureDrop Workstation RPM 0.5.4

[eloquence]

This is a ticket to track the next version of the SecureDrop Workstation RPM, which will ship an updated keyring, fedora-33 as the new default template, and other changes that have recently landed in main.

Release date: 2021-06-01
Release manager: @creviera
Deputy release manager: @conorsch
Communications manager:: @eloquence

• Update to keyring
• Confirm https://yum.qubes-os.org/r4.0/current/vm/fc33/rpm/qubes-mgmt-salt-4.0.25-1.fc33.noarch.rpm has been released (this link will not be broken if it has; tracking here: https://yum.qubes-os.org/r4.0/current-testing/vm/fc33/rpm/qubes-mgmt-salt-4.0.25-1.fc33.noarch.rpm)
• Update changelog and tag
• Create test plan
• Prepare test package for yum-test
• Complete QA
• Production release and comms

[sssoleileraaa]

Test Plan: https://github.com/freedomofpress/securedrop-workstation/wiki/0.5.4-Test-Plan

[sssoleileraaa]

https://yum.qubes-os.org/r4.0/current/vm/fc33/rpm/qubes-mgmt-salt-4.0.25-1.fc33.noarch.rpm still has not been released and is blocking, right?

[conorsch]

According to #695 (comment) (and I verified myself after that comment), it was indeed published, but I'm seeing the same behavior you are: it's no longer there. Perhaps we're seeing a regression related to the repo outage. Let's check upstream for related reports.

[eloquence]

I commented here QubesOS/qubes-issues#6580 (comment)

[eloquence]

Marek was quick to help, 4.0.25 packages are now up again: https://yum.qubes-os.org/r4.0/current/vm/fc33/rpm/

[conorsch]

What a gem. Thanks for the quick follow-up!

[eloquence]

I'm currently testing a fresh install from main (i.e. without signing key changes). I'll note that I've repeatedly encountered issues with qubes-template-securedrop-workstation not being installable, both during this run and previously. This appears unrelated to our signing key fun; the errors are logged as "Unable to find a match" in /var/log/dnf.log on dom0.

My impression is that there are some complex dnf / rpm cache interactions that sometimes cause problems, possibly including the dnf instance in sys-firewall as well. What worked to resolve it was to use qubes-dom0-update with --action=reinstall and then manually dnf install the downloaded file in dom0.

After this run I may try once more to put my system in an absolutely pristine state to see if I can still reproduce this issue.

[eloquence]

Once the above issue was resolved, I tested a fresh install from main. Please note: For this run, I did not re-download fedora-33 (but was otherwise fully configured on fedora-32).

fedora-33 migration

• Observe that sys-firewall, sys-net and sys-usb are all based on fedora-33.
• Observe that qvm-prefs default-mgmt-dvm template shows fedora-33

update-xfce-settings fixes

1. • Observe that "Suspend" and "Hibernate" options are not available in the top right user menu in Qubes, or on the "Log out" screen from the application menu. This confirms that the update-xfce-settings script is still doing its job.
2. In dom0, run sudo /srv/salt/update-xfce-settings
3. • Observe that the script exits with "This script should not be run as root"

detailed logging and improved error handling

1. Modify your copy of /srv/salt/update-xfce-settings to exit 1 immediately
2. Run the updater with /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0
3. • Observe that the updater ultimately reports an error
4. • Observe that the apply_dom0 error is logged in ~/.securedrop_launcher/logs/launcher.log, and that details are available in ~/.securedrop_launcher/logs/launcher-detail.log (launcher-detail.log is newly added in this release).
5. Undo your local modification

[eloquence]

Tested an update from 0.5.2 (fedora-32, with fedora-33) to current main.

The fedora-33 migration worked, but sys VMs did not come back up after the update, reporting libxenlight errors. This is typically associated with memory limitations, and I saw this previously as well; this system has only 16GB of RAM, so hopefully this will not be an issue with prod machines, where 32GB RAM is a requirement. In any event, the updater prompted for a reboot, which cleared up the issue.

fedora-33 migration

• Observe that sys-firewall, sys-net and sys-usb are all based on fedora-33.
• Observe that qvm-prefs default-mgmt-dvm template shows fedora-33

update-xfce-settings fixes

1. • Observe that "Suspend" and "Hibernate" options are not available in the top right user menu in Qubes, or on the "Log out" screen from the application menu. This confirms that the update-xfce-settings script is still doing its job.
2. In dom0, run sudo /srv/salt/update-xfce-settings
3. • Observe that the script exits with "This script should not be run as root"

detailed logging and improved error handling

Not re-tested, but launcher-detail.log populated as expected.

[eloquence]

This was released earlier today, and we've notified existing users of the update. We'll monitor in case of issues. Thanks @creviera for managing this release!