Release securedrop-workstation 0.3.0

[emkll]

This is a placeholder to track the release of the securedrop-workstation 0.3.0 RPM containing updated provisioning code.

QA Period

• Update version and changelog SecureDrop Workstation 0.3.0~rc1 #550
• Finalize test plan based on changelog above
• Cut release candidate tag https://github.com/freedomofpress/securedrop-workstation/releases/tag/0.3.0-rc1
• Upload package to dev rpm server: SecureDrop Workstation 0.3.0-rc1 securedrop-yum-test#8
• Perform QA

Final Release

• Cut/sign release tag
• Sign package with release key
• Upload package to prod rpm server Release Securedrop Workstation dom0 0.3.0 config RPM securedrop-yum-prod#7
• Let pilot orgs know of any fixes that are relevant for them

Release-specific test plan

Draft added by @eloquence below, 2020-05-19

Scenario: Fresh install

Fixes for #527 (merged in #530) and #514 (merged in #535)

• During a fresh install of 0.3.0, observe that you do not see the error "Recurse failed: none of the specified sources were found".
• During a fresh install of 0.3.0, observe that you do not see errors like "Temporary failure resolving 'apt-test.freedom.press'" that cause the installation to fail

Scenario: Running preflight updater

#522, and #531 (merged in #532)

• Run the command tail -f ~/.securedrop_launcher/logs/launcher.logs in a dom0 terminal (you can touch the file to create it if it does not exist yet). This will give you a real-time view of log entries added by the updater.
• Run the preflight updater manually from dom0 using /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0 (this ensures that it will run even if no updates are available)
• After the "checking for updates" stage and before applying updates, launch the VM sd-app-buster-template.
• Observe that sd-app-buster-template is shut down in the final stage of the update
• Observe that sys-usb is successfully restarted after updates

Scenario: Post-install configuration

#526 and #529 (merged in #533)

• Apply sd-send-app-clipboard, sd-receive-app-clipboard and sd-receive-logs tag to select VMs by following the end user documentation. See the detailed test plan in freedomofpress/securedrop-workstation#533, as well:
  • Observe that RPC policies for qvm-copy are in effect where expected
  • Observe that RPC policies for copy & paste are in effect where expected and you can copy and paste between VMs
  • Observe that qvm-copy and qvm-copy-to-vm commands are still prohibited for VMs not whitelisted via tags
  • Observe that clipboard operations are still prohibited for VMs not whitelisted via tags

Scenario: Uninstall

#526

• Observe that custom RPC tags added during testing are successfully removed
• Observe that RPC policies in /etc/qubes-rpc/policy/qubes.ClipboardPaste and /etc/qubes-rpc/policy/qubes.Filecopy are reset to their original values

[eloquence]

(Added draft test plan to issue body.)

[eloquence]

• Environment type: Qubes staging
• Client version: SecureDrop Client nightly, but not tested here
• Workstation version: SecureDrop Workstation 0.3.0~rc1
• Server version: 1.3.0 (Qubes staging env)

Scenario: Uninstall

Starting with uninstall of my automatically updated RPM so I can do a fresh install of RC1:

• Added tags to VMs per test plan
• Observe that custom RPC tags added during testing are successfully removed (see output below)
• Observe that RPC policies in /etc/qubes-rpc/policy/qubes.ClipboardPaste and /etc/qubes-rpc/policy/qubes.Filecopy are reset to their original values

Tag removal output:

----------
          ID: remove-rpc-policy-tags
    Function: cmd.script
        Name: salt://remove-tags
      Result: True
     Comment: Command 'salt://remove-tags' run
     Started: 15:55:16.985669
    Duration: 565.528 ms
     Changes:   
              ----------
              pid:
                  11943
              retcode:
                  0
              stderr:
              stdout:
                  Removing tag 'sd-send-app-clipboard' from VM 'sd-journalist'.
                  Removing tag 'sd-receive-app-clipboard' from VM 'sd-journalist'.
                  Removing tag 'sd-send-app-clipboard' from VM 'vault'.
                  Removing tag 'sd-receive-logs' from VM 'work'.
----------

[eloquence]

Fresh install

• During a fresh install of 0.3.0, observe that you do not see the error "Recurse failed: none of the specified sources were found".
• During a fresh install of 0.3.0, observe that you do not see errors like "Temporary failure resolving 'apt-test.freedom.press'" that cause the installation to fail

Note: I did see #519 during the first run, but unfortunately lost the output from that. Second run resolved.

[eloquence]

Scenario: Running preflight updater

#522, and #531 (merged in #532)

• Run the command tail -f ~/.securedrop_launcher/logs/launcher.logs in a dom0 terminal (you can touch the file to create it if it does not exist yet). This will give you a real-time view of log entries added by the updater.
• Run the preflight updater manually from dom0 using /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0 (this ensures that it will run even if no updates are available)
• After the "checking for updates" stage and before applying updates, launch the VM sd-app-buster-template.
• Observe that sd-app-buster-template is shut down in the final stage of the update
• Observe that sys-usb is successfully restarted after updates

Scenario: Post-install configuration

#526 and #529 (merged in #533)

• Apply sd-send-app-clipboard, sd-receive-app-clipboard and sd-receive-logs tag to select VMs by following the end user documentation. See the detailed test plan in freedomofpress/securedrop-workstation#533, as well:
  • Observe that RPC policies for qvm-copy are in effect where expected
  • Observe that RPC policies for copy & paste are in effect where expected and you can copy and paste between VMs
  • Observe that qvm-copy and qvm-copy-to-vm commands are still prohibited for VMs not whitelisted via tags (spot-checked)
  • Observe that clipboard operations are still prohibited for VMs not whitelisted via tags (spot-checked)

[eloquence]

Scenario: fedora-31 upgrade

Environment type: Qubes staging,
Client version: 20200526 nightly
Workstation version: 0.3.0rc1
Server version: SecureDrop 1.3.0 staging, Qubes environment

Updated to fedora-31.

• Upgrade succeeded without user-facing errors (Salt error/traceback printed on console, see Audit and suppress CRITICAL messages in install #559; progress bar misleading, see Updater progress bar should account for large template updates securedrop-updater#19)
• User gets prompted for reboot
• sys-net, sys-usb and sys-firewall updated to fedora-31
• Client passes initial smoke test

Now re-testing export flow.

[eloquence]

🎉 USB auto-attach logic to sd-devices still working beautifully after fedora-31 upgrade was applied to sys-usb (tested with block device and unsupported printer)

[zenmonkeykstop]

• Installed 0.2.4(prod), upgraded to 0.3.0-rc2 via preflight updater as per wiki instructions.
• Added sd-receive-app-clipboard, sd-receive-logs, sd-send-app-clipboard tags to vault VM

Scenario: Post-install configuration

• Observe that RPC policies for qvm-copy are in effect where expected verified for sd- VMs
• Observe that RPC policies for copy & paste are in effect where expected and you can copy and paste between VMs verified for sd-app and vault VM pair
• Observe that qvm-copy and qvm-copy-to-vm commands are still prohibited for VMs not whitelisted via tags verified for sd- VMs, sd-log and vault pair
• Observe that clipboard operations are still prohibited for VMs not whitelisted via tags verified for sd-app and work VM

[emkll]

Closed via freedomofpress/securedrop-yum-prod#7