Release securedrop-workstation-0.5.3 and securedrop-workstation-config 0.1.6

[eloquence]

This issue serves as a combined tracking ticket for these two interdependent releases. See the following PRs for final pre-release testing notes (accounting for the fact that packages are now being served on yum-test and apt-test):
#661
freedomofpress/securedrop-builder#221

[eloquence]

Observations from testing:

Update logic

• /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0 upgraded packages to 0.5.3 (rpm) and 0.1.6 (deb) without issue.
• Updater detected the need for a full migration and performed it, requesting a reboot at the end of the process.

Fail Closed behavior fixes

• Default mailcap rules were provisioned correctly to sd-app, sd-viewer, sd-proxy, and sd-devices private volumes (symlinking to file provided via package).
• Attempting to open files in those VMs via run-mailcap fails, and the attempt is logged in /var/log/syslog.
• Attempting to open file in sd-devices from sd-app via qvm-open-in-vm correctly delegates opening to a disposable VM.

Disposable VM configuration improvements

• qrexec-client-vm ‘@dispvm’ qubes.GetImageRGBA < /dev/urandom in sd-log or an sd-viewer based disposable VM does not open a disposable VM
• qvm-prefs sd-viewer default_dispvm returns empty output.

[eloquence]

Basic app regression testing

• Files opened from SecureDrop client still open in disposable VMs as expected
• Export logic still works

[conorsch]

Looks good! Ran through a similar test plan:

Update logic

• Using the GUI launcher upgraded packages to 0.5.3 (rpm) and 0.1.6 (deb) without issue.
• Updater detected the need for a full migration and performed it, requesting a reboot at the end of the process.

Fail Closed behavior fixes

• Default mailcap rules were provisioned correctly to sd-app, sd-viewer, sd-proxy, and sd-devices private volumes (symlinking to file provided via package).
• Attempting to open files in those VMs via run-mailcap fails, and the attempt is logged in /var/log/syslog.
• Attempting to open file in sd-devices from sd-app via qvm-open-in-vm correctly delegates opening to a disposable VM.

Disposable VM configuration improvements

• qrexec-client-vm @dispvm qubes.GetImageRGBA < /dev/urandom in sd-log or an sd-viewer based disposable VM does not open a disposable VM
• qvm-prefs sd-viewer default_dispvm returns empty output.

Basic app regression testing

• Files opened from SecureDrop client still open in disposable VMs as expected
• Export logic still works
  • I didn't test USB export flow, don't have a provisioned USB device on hand.

Misc

There was one small hiccup I noticed during testing, which I don't believe is related to the release changes, and so shouldn't block promotion to prod. After the updater completed and I rebooted, I wasn't able to start the Client from the desktop icon. Checking the logs, it the lock blocked it from starting. While I could have run gtk-launch securedrop-client myself, I didn't, and instead rebooted again. The Client started without issue. Here are the logs from that session:

2021-03-10 14:32:45,462 - sdw_updater_gui.UpdaterApp:77(upgrade_status) INFO: Signal: upgrade_status {'recommended_action': <UpdateStatus.REBOOT_REQUIRED: '2'>, 'dom0': <UpdateStatus.REBOOT_REQUIRED: '2'>, 'apply_dom0': '0'}
2021-03-10 14:32:45,465 - sdw_updater_gui.UpdaterApp:82(upgrade_status) INFO: Reboot required
2021-03-10 14:34:22,818 - sdw_updater_gui.UpdaterApp:145(reboot_workstation) INFO: Rebooting the workstation
2021-03-10 14:37:06,546 - __main__:46(main) INFO: Starting SecureDrop Launcher
2021-03-10 14:37:06,549 - sdw_updater_gui.Updater:451(should_launch_updater) INFO: Required reboot performed, updating status and launching client.
2021-03-10 14:37:06,549 - sdw_updater_gui.Updater:216(_write_updates_status_flag_to_disk) INFO: Setting update flag to 0 in sd-app
2021-03-10 14:37:42,498 - sdw_util.Util:70(obtain_lock) ERROR: Error obtaining lock on '/run/user/1000/sdw-launcher.lock'. Process may already be running.
2021-03-10 14:38:51,331 - sdw_util.Util:70(obtain_lock) ERROR: Error obtaining lock on '/run/user/1000/sdw-launcher.lock'. Process may already be running.
2021-03-10 14:39:26,729 - sdw_util.Util:70(obtain_lock) ERROR: Error obtaining lock on '/run/user/1000/sdw-launcher.lock'. Process may already be running.
2021-03-10 14:39:28,044 - sdw_util.Util:70(obtain_lock) ERROR: Error obtaining lock on '/run/user/1000/sdw-launcher.lock'. Process may already be running.
2021-03-10 14:44:21,392 - __main__:46(main) INFO: Starting SecureDrop Launcher
2021-03-10 14:44:21,400 - sdw_updater_gui.Updater:451(should_launch_updater) INFO: Required reboot performed, updating status and launching client.
2021-03-10 14:44:21,401 - sdw_updater_gui.Updater:216(_write_updates_status_flag_to_disk) INFO: Setting update flag to 0 in sd-app
2021-03-10 14:44:39,908 - sdw_updater_gui.Updater:225(_write_updates_status_flag_to_disk) INFO: Setting update flag to 0 in dom0
2021-03-10 14:44:39,909 - sdw_updater_gui.UpdaterApp:27(launch_securedrop_client) INFO: Launching SecureDrop client

Noting it here strictly for completeness's sake. Moving forward with promoting these packages to prod.

[eloquence]

There was one small hiccup I noticed during testing, which I don't believe is related to the release changes, and so shouldn't block promotion to prod. After the updater completed and I rebooted, I wasn't able to start the Client from the desktop icon. Checking the logs, it the lock blocked it from starting. While I could have run gtk-launch securedrop-client myself, I didn't, and instead rebooted again.

The preflight updater starts automatically after OS login. If it detects that no updates are required (because of a recent update), it silently proceeds to launch the app without ever showing the updater window. If you double-clicked the icon at the same time, it would have correctly complained in the logs that it's already running -- but the app window should come up shortly therafter. Is that consistent with what you observed?

[conorsch]

No, the app window never drew. You can see my repeated attempts to open the app via the desktop icon spread across nearly 2m, at which point I rebooted.

[eloquence]

Interesting. I wonder if it's the lock that caused the problem or if there was some other problem launching the app. Worth investigating/observing further, will file separate issue.

[eloquence]

(Closing since the release is in prod now.)