search

freedomofpress / securedrop-workstation

Qubes-based SecureDrop Journalist Workstation environment for submission handling
GNU Affero General Public License v3.0
135 stars 39 forks source link

Release SecureDrop Workstation 0.3.1 #571

Closed eloquence closed 4 years ago

eloquence commented 4 years ago

This is an issue to track the production release of the SecureDrop Workstation 0.3.1 RPM package, which ships the keyring update in #563.

RC preparation

Test plan:

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

Release workflow

conorsch commented 4 years ago

When reporting the results of ad-hoc tests against SecureDrop Workstation, please include the following information:

Environment:

Test purpose:

Confirming keyring updates in Debian-based VMs

Test steps:

Following test plan above

Test results:

Success! Used the one-liner in the test plan above, and confirmed that all VMs listed had the new 2021 key expiry.

Comments:

Proceeding with prod scenario next....

eloquence commented 4 years ago

Staging report

Tested on a 0.3.0-staging enviroment that I upgraded to 0.3.1-rc1; then I ran securedrop-admin --apply to apply the configuration.

Detailed output from the very helpful one-liner here: https://gist.github.com/eloquence/e9b4da12fb9bfeca2606d2def1b67bb5

$ grep 2020 output.txt | wc -l
0
$ grep 2021 output.txt | wc -l
14
conorsch commented 4 years ago

Environment:

Test purpose:

Confirming keyring updates for RPM-based components, i.e. dom0 & sys-firewall

Test steps:

Following test plan above for prod testing

Test results:

:x: Test plan as described can't pass, needs to be rethought. The prod install logic references, naturally, the apt.freedom.press for TemplateVMs, but the securedrop-keyring package doesn't exist on apt.freedom.press yet, so the first-time install fails.

Click to expand ``` ---------- ID: sd-log-remove-rsyslog-qubes-plugin Function: cmd.run Name: /rw/config/rc.local Result: False Comment: Command "/rw/config/rc.local" run Started: 17:25:02.434658 Duration: 24.718 ms Changes: ---------- pid: 959 retcode: 5 stderr: Failed to start securedrop-log.service: Unit securedrop-log.service not found. stdout: Summary for sd-log ------------ Succeeded: 1 (changed=2) Failed: 1 ------------ Total states run: 2 Total run time: 52.619 ms Traceback (most recent call last): File "/usr/bin/securedrop-admin", line 67, in provision_all subprocess.check_call([os.path.join(SCRIPTS_PATH, "scripts/provision-all")]) File "/usr/lib64/python3.5/subprocess.py", line 271, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['/usr/share/securedrop-workstation-dom0-config/scripts/provision-all']' returned non-zero exit status 20 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/bin/securedrop-admin", line 171, in main() File "/usr/bin/securedrop-admin", line 148, in main provision_all() File "/usr/bin/securedrop-admin", line 69, in provision_all raise SDAdminException("Error during provision-all") __main__.SDAdminException: Error during provision-all [user@dom0 ~]$ ```

Comments:

Typically for rc testing we'd use the procedure described in https://github.com/freedomofpress/securedrop-workstation/wiki/Workstation-dom0-QA-testing#upgrade-install-testing, but that approach would clobber the test key, rendering local testing moot.

eloquence commented 4 years ago

Prod report

tl;dr: While the --apply run threw errors as a result of the missing package, the critical portions of the test plan succeeded.

conorsch commented 4 years ago

Sounds good, thanks for the clarity, and for pressing ahead with the pubkey verification steps despite the failure in the --apply action, @eloquence. I'm able to confirm that the prod pubkey was added, despite the mismatch on the apt repository config leading to a failed task.

Make a timeboxed attempt to revise the test plan for prod to use apt-test for domUs, but prod repos for dom0, via the following patch:

--- /srv/salt/sd-default-config.yml    2020-06-10 15:35:57.000000000 -0700
+++ /tmp/sd-default-config.yml    2020-06-15 09:42:28.600644786 -0700
@@ -2,8 +2,10 @@
 # Production variables, for use with real-world installs
 prod:
   dom0_yum_repo_url: "https://yum.securedrop.org/workstation/dom0/f25"
-  apt_repo_url: "https://apt.freedom.press"
-  signing_key_filename: "securedrop-release-signing-pubkey.asc"
+  #apt_repo_url: "https://apt.freedom.press"
+  #signing_key_filename: "securedrop-release-signing-pubkey.asc"
+  apt_repo_url: "https://apt-test.freedom.press"
+  signing_key_filename: "apt-test-pubkey.asc"
 # Development variables, suited for use during local development
 dev:
   dom0_yum_repo_url: "https://yum-test.securedrop.org/workstation/dom0/f25"

Unfortunately that's also insufficient for testing here—while the securedrop-admin --apply action completes without error, the gpg verification commands in the test plan show the test key for dom0, due to the patch on the signing_key_filename specifically.

Given how thoroughly we've tested the various environments, I'm satisfied with results from rc1, and suggest proceeding with 0.3.1 final release. The OP has been updated with specific steps documenting the release workflow for 0.3.1.

eloquence commented 4 years ago

This part is succeeded in my prod environment after applying updates, now that the prod deb packages are up (still using the RC1 RPM).

conorsch commented 4 years ago

Release is live.