Release SecureDrop Workstation 0.5.0

[eloquence]

Release date: November 4, 2020

This is a tracking issue for preparing the next release of the SecureDrop Workstation, which will ship consolidated templates via the preflight updater (#471), as well as other unreleased changes from main.

In addition to an RPM update, we will simultaneously issue new releases of most SecureDrop Workstation components, including the SecureDrop Client. These have their own versioning, but for simplicity, this issue uses "0.5.0" as a shorthand for the cross-component release.

This release will include also include release to other workstation components:

• securedrop-client:
  • Update changelog
  • Perform QA
  • Push signed tag
  • Update packaging repo
• securedrop-proxy
  • Update changelog
  • Perform QA
  • Push signed tag
  • Update packaging repo
• securedrop-viewer
  • Update changelog
  • Perform QA
  • Push signed tag
  • Update packaging repo
• securedrop-log
  • Update changelog
  • Perform QA
  • Push signed tag
  • Update packaging repo
• securedrop-export
  • Update changelog
  • Perform QA
  • Push signed tag
  • Update packaging repo
• securedrop-workstation-config
  • Update changelog
  • Perform QA
  • Push signed tag
  • Update packaging repo

Release steps

Prepare

• Push signed tags for applications (client/proxy/log/export)

  • https://github.com/freedomofpress/securedrop-export/tree/0.2.4
  • https://github.com/freedomofpress/securedrop-log/tree/0.1.2
  • https://github.com/freedomofpress/securedrop-proxy/tree/0.3.1
  • https://github.com/freedomofpress/securedrop-client/tree/0.3.0

• Packaging changes including debian changelog for all packages Updated buster changelogs for securedrop-client, -export, -log, -proxy securedrop-builder#207

• Merge packaging changes and pushed signed tag to securedrop-debian-packaging https://github.com/freedomofpress/securedrop-debian-packaging/releases/tag/0.2.13

• Build production debs

• Open PR to securedrop-debian-packages LFS repo, sign release file and open PR: https://github.com/freedomofpress/securedrop-debian-packages-lfs/pull/37

• Open PR containing final release commit for securedrop-workstation

• Merge and sign tag for workstation repo

• Build and sign securedrop-workstation-dom0-config rpm

• Open PR to securedrop-workstation-prod-rpm-packages LFS repo : Release securedrop-workstation-dom0-config 0.5.0 securedrop-yum-prod#12

Release

• Merge debian packages into main
• Merge RPMs into main
• Update docs

Test plan

Please see the 0.5.0 test plan on the wiki.

[eloquence]

During the 10/15-10/28 sprint, we're aiming to land the remaining changes in #471 (and the reply badges release blocker freedomofpress/securedrop-client#1149) and then begin the QA of all components. The actual release will likely happen in early November.

[eloquence]

Started building out the combined non-template consolidation test plan in this issue; see changelog tracking doc for current status. Still a couple of client changes to cover, will add those tomorrow.

[eloquence]

The test plan in this issue now fully reflects the selection and prioritization in the changelog tracking doc. What remains is:

• review of the test plan by other team members
• incorporation of template consolidation testing into the test plan

As a reminder, the database migration in freedomofpress/securedrop-client#1162 is a release blocker, and we should not kick off full pre-release QA until it lands.

[conorsch]

Completed a happy-path upgrade on hardware.

Release-specific test plan

Test parameters

• Hardware target: e.g. Thinkpad T490 20N20046US
• Install type: "happy path" upgrade
• securedrop-workstation-dom0-config version: 0.4.0 prod
• Release candidate version: 0.5.0-rc2

Scenario: Template consolidation:

Install Type 2: Happy Path Upgrade:

• Complete a production workstation setup following the installation instructions.
• Start the SecureDrop Client and Verify that its version in the login dialog footer is 0.2.1
• As the primary test journalist user, submit a reply to a source via the client.
• in a networked VM (work, say):
  • clone the https://github.com/freedomofpress/securedrop-workstation.git repo and ensure that it is on the main branch
• in dom0:
  • transfer the repo to dom0 using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
  • update the Salt config to use QA repos using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
  • update the workstation config RPM via sudo qubes-dom0-update -y and verify that it is now the release candidate with dnf list securedrop-workstation-dom0-config
  • verify that the pre-consolidation templates are still in use via qvm-ls --tags sd-workstation
  • update the Salt config again, using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
  • remove the updater flag files, if they exist, with rm ~/.securedrop_launcher/sdw-{last_updated,update-status}
• Double-click the SecureDrop icon to start the updater, and run tail -f ~/securedrop_launcher/logs/launcher.log in dom0
• Verify that the installation completes successfully.
• In dom0, run `qvm-ls --tags sd-workstation, and verify that:
  • the only TemplateVMs listed for AppVMs are sd-(large|small)-buster-template) and securedrop-workstation-buster.
  • sd-app, sd-log, sd-proxy, and sd-gpg are based on sd-small-buster-template
  • sd-devices-dvm and sd-viewer are based on sd-large-buster-template
• Perform a timed run of the updater via the dom0 command: time /opt/securedrop/launcher/sdw-launcher.py --skip-delta=0 and record the time here: 10m6s

Scenario: Use of sdw-admin

Test case: securedrop-admin to sdw-admin rename (Issue: #586; PR: #596)

• Observe that securedrop-admin can no longer be run in dom0
• Observe that you can now access the tool with sdw-admin in dom0
• Observe that sdw-admin --validate still functions as expected

Scenario: Running the preflight updater

Test case: Text scaling in preflight updater (Issue: #597; PR: #599)

• Under "System ▶ Appearance ▶ Fonts" in dom0, note the current font size of the "Default Font", then increase it to a very high value, e.g., 17.
• Run the GUI updater, via /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0. Complete the updater process while observing the following:
• Observe that no text in the updater GUI is cut off
• Observe that you cannot cause text to be cut off by resizing the window
• After the update completes, restore the font size to the previous value.

Scenario: Investigating logs

Test case: Sorting logs by hostname (Issue: #583; PR: freedomofpress/securedrop-log#18)

• Observe that no host directory exists in ~/QubesIncomingLogs on sd-log (only relevant for "Fresh install" scenario, otherwise the directory will be present)
  • host dir did exist, as expected, given install base of 0.4.0 prod
• Run the command logger LOGME in sd-app, sd-whonix, and sd-log.
• Observe that the line was added to ~/QubesIncomingLogs/sd-app and ~/QubesIncomingLogs/sd-whonix
• Observe that no sd-log directory exists in ~/QubesIncomingLogs on sd-log.

[eloquence]

• Hardware target: Thinkpad T480
• Install type: sad path upgrade
• securedrop-workstation-dom0-config version: 0.4.0
• Release candidate version: 0.5.0-rc2

Install Type 3: Sad Path Upgrade:

• Complete a production workstation setup following the installation instructions.
• Start the SecureDrop Client and Verify that its version in the login dialog footer is 0.2.1
• As the primary test journalist user, submit a reply to a source via the client.
• in a networked VM (work, say):
  • clone the https://github.com/freedomofpress/securedrop-workstation.git repo and ensure that it is on the main branch
• in dom0:
  • transfer the repo to dom0 using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
  • update the Salt config to use QA repos using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
  • remove the updater flag files, if they exist, with rm ~/.securedrop_launcher/sdw-{last_updated,update-status}
• Reboot the machine. When the GUI updater launches, leave it open without clicking Continue
• in dom0:
  • verify the config RPM version is 0.4.0.1-fc25, with dnf list securedrop-workstation-dom0-config
  • verify that the pre-consolidation templates are still in use via qvm-ls --tags sd-workstation
• In the updater, click Continue to start the update, and run tail -f ~/securedrop_launcher/logs/launcher.log in dom0
• Verify that the updater completes without error

(Reboot requested at this stage, which I performed.)

• Verify that the client fails to start when the Securedrop icon is double-clicked.
• in dom0:
  • verify the config RPM version is now 0.5.0.*-fc25, with dnf list securedrop-workstation-dom0-config
  • ❌ verify that the pre-consolidation templates are still in use via qvm-ls --tags sd-workstation

I'm seeing only references to sd-small-buster-template and sd-large-buster-template, and the old templates no longer exist. Given the reboot, this is likely expected behavior.

• update the Salt config to use QA repos using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
• run sdw-admin --apply to apply the correct template configuration.
• Verify that the installation completes successfully.
• ❌ Verify that the client starts when the SecureDrop desktop icon is double-clicked, and its version is 0.2.2

Double-clicking icon does nothing, getting an error: sd-app: command failed with code: 2 if running launcher via CLI. VM indicates update pending, so I'm rebooting the whole system. After reboot, we're good:

• Verify that the client starts when the SecureDrop desktop icon is double-clicked, and its version is ..

Except that the version is 0.2.1-dev-20201029-164632 because we're using a nightly build that overrides the 0.3.0 version configured in the securedrop-client repo. I've updated that in the test plan.

• In dom0, run qvm-ls --tags sd-workstation, and verify that:
  • the only TemplateVMs listed are sd-(large|small)-buster-template) and securedrop-workstation-buster.

And sd-devices-dvm for sd-devices.

• sd-app, sd-log, sd-proxy, and sd-gpg are based on sd-small-buster-template
• ❌ sd-devices and sd-viewer are based on sd-large-buster-template

sd-devices is listed as using the template sd-devices-dvm, and sd-devices-dvm is listed as using the template sd-large-buster-template.

• Verify that client login and basic functionality are working.

Updater runtime:

real 8m38.093s
user 0m15.941s
sys 0m11.154s

Scenario: Use of sdw-admin

Test case: securedrop-admin to sdw-admin rename (Issue: #586; PR: #596)

• Observe that securedrop-admin can no longer be run in dom0
• Observe that you can now access the tool with sdw-admin in dom0
• Observe that sdw-admin --validate still functions as expected

Scenario: Running the preflight updater

Test case: Text scaling in preflight updater (Issue: #597; PR: #599)

• Under "System ▶ Appearance ▶ Fonts" in dom0, note the current font size of the "Default Font", then increase it to a very high value, e.g., 17.
• Run the GUI updater, via /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0. Complete the updater process while observing the following:
• Observe that no text in the updater GUI is cut off
• Observe that you cannot cause text to be cut off by resizing the window
• After the update completes, restore the font size to the previous value.

Scenario: Using the SecureDrop Client

Test case: Preview snippets (Issue: freedomofpress/securedrop-client#1121; PR: freedomofpress/securedrop-client#1131)

• Log into the SecureDrop Client
• Before the client has finished decrypting all messages and replies, send a reply to an existing user
• Observe that a preview of that reply is shown underneath the source name in the source list to the left, once it has been successfully sent
• Wait for all messages/replies to be decrypted
• Observe that during the sync, the preview snippet continues to show the reply you sent

Test case: Window resizing (Issues: freedomofpress/securedrop-client#1109 and freedomofpress/securedrop-client#1120; PRs: freedomofpress/securedrop-client#1130 and freedomofpress/securedrop-client#1145)

• Observe that the client window is maximized with no part of the client hidden from view
• Click on the square resize icon in the upper right-hand corner
• Observe that the client window is changed to a smaller size, with no part of the window hidden from view (horizontal scrolling within the conversation view may be required)
• Resize the client window manually by dragging its corner
• Observe for multiple sources that during resizing, source abbreviations are elided at lower resolutions as shown in this GIF
• Click a few times on the square resize icon in the upper right corner
• Observe that the client switches back and forth between maximum size and your chosen size, with no part of the window hidden from view

Test case: Reply badges feature (Issue: freedomofpress/securedrop-client#76; PR: freedomofpress/securedrop-client#1142)

• Log into the SecureDrop Client and wait for it to sync.
• Observe that all previously sent replies show a two-letter badge representing the reply author. If first name and last name are set, lower-case initials will be used; otherwise, the first two letters of the username will be used.
• Send a reply.
• Observe that the sent reply shows a two-letter badge representing your account.
• Observe that the badge for replies you have sent is in a different color than the badge for replies sent by other users.
• Through the Journalist Interface, delete account X. (Stay logged into the JI for a later step.)
• Wait for the SecureDrop Client to synchronize with the server.
• Observe that replies sent by account X are now attributed to a placeholder user, represented by a star cluster icon.
• Through the Journalist Interface, change the first and last name of the user logged into the SecureDrop Client to names with different initial.
• Wait for the SecureDrop Client to synchronize with the server.
• Observe that the updated initials are shown in reply badges, and in the login badge (top left corner).
• Switch to offline mode
• Observe that all reply badges are still present, but are now in a uniform color, even if sent by the previously logged in user.

Test case: Decryption error styling (Issue: freedomofpress/securedrop-client#1150; PR: freedomofpress/securedrop-client#1151)

• Log out of the SecureDrop Client
• Via the Source Interface, send a message as a new source
• Via the Journalist Interface, send a reply to that source
• In sd-gpg, temporarily move ~/.gnupg to ~/.gnupg.bak to cause decryption errors
• Log into the SecureDrop Client and wait for it to sync
• Observe that message and reply are styled identically, in gray and italics: "cannot decrypt message" / "cannot decrypt reply"
• In sd-gpg, move ~/.gnupg.bak back to ~/.gnupg

Scenario: Investigating logs

Test case: Sorting logs by hostname (Issue: #583; PR: freedomofpress/securedrop-log#18)

• Observe that no host directory exists in ~/QubesIncomingLogs on sd-log (only relevant for "Fresh install" scenario, otherwise the directory will be present)
• Run the command logger LOGME in sd-app, sd-whonix, and sd-log.
• Observe that the line was added to ~/QubesIncomingLogs/sd-app and ~/QubesIncomingLogs/sd-whonix
• Observe that no sd-log directory exists in ~/QubesIncomingLogs on sd-log.

[eloquence]

(In spite of the ❌s, all good news so far; as far as I can tell the sd-devices-dvm output is just an artifact of how that particular VM works, given the persistent-name disposable VM approach.)

[sssoleileraaa]

• Hardware target: Thinkpad T480
• Install type: freshhh path upgrade

Install Type 1: Fresh Install:

• Follow the installation instructions to copy the submission key and journalist interface config details into place, then follow the steps below to download and install the workstation RPM.
• in a networked VM (work, say):
  • download the latest securedrop-workstation-dom0-config version (sdw-latest.rpm, say) from https://yum-test.securedrop.org/workstation/dom0/f25/
  • clone the https://github.com/freedomofpress/securedrop-workstation.git repo and ensure that it is on the main branch
• in dom0:
  • transfer the RPM to dom0 using qvm-run --pass-io work "cat sdw-latest.rpm" > sdw-latest.rpm
  • transfer the repo to dom0 using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
  • install the RPM using sudo dnf install sdw-latest.rpm
  • update the Salt config to use QA repos using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
  • set up the workstation using the command sdw-admin --apply
• Verify that the installation completes successfully.
• In dom0, run qvm-ls --tags sd-workstation, and verify that:
  • the only TemplateVMs listed are sd-(large|small)-buster-template) and securedrop-workstation-buster.
  • sd-app, sd-log, sd-proxy, and sd-gpg are based on sd-small-buster-template
  • sd-devices and sd-viewer are based on sd-large-buster-template

Scenario: Use of sdw-admin

Test case: securedrop-admin to sdw-admin rename (Issue: #586; PR: #596)

• Observe that securedrop-admin can no longer be run in dom0
• Observe that you can now access the tool with sdw-admin in dom0
• Observe that sdw-admin --validate still functions as expected

Scenario: Running the preflight updater

Test case: Text scaling in preflight updater (Issue: #597; PR: #599)

• Under "System ▶ Appearance ▶ Fonts" in dom0, note the current font size of the "Default Font", then increase it to a very high value, e.g., 17.
• Run the GUI updater, via /opt/securedrop/launcher/sdw-launcher.py --skip-delta 0. Complete the updater process while observing the following:
• Observe that no text in the updater GUI is cut off
• Observe that you cannot cause text to be cut off by resizing the window
• After the update completes, restore the font size to the previous value.

Scenario: Using the SecureDrop Client

Test case: Preview snippets (Issue: freedomofpress/securedrop-client#1121; PR: freedomofpress/securedrop-client#1131)

• Log into the SecureDrop Client
• Before the client has finished decrypting all messages and replies, send a reply to an existing user
• Observe that a preview of that reply is shown underneath the source name in the source list to the left, once it has been successfully sent
• Wait for all messages/replies to be decrypted
• Observe that during the sync, the preview snippet continues to show the reply you sent

Test case: Window resizing (Issues: freedomofpress/securedrop-client#1109 and freedomofpress/securedrop-client#1120; PRs: freedomofpress/securedrop-client#1130 and freedomofpress/securedrop-client#1145)

• Observe that the client window is maximized with no part of the client hidden from view
• Click on the square resize icon in the upper right-hand corner
• Observe that the client window is changed to a smaller size, with no part of the window hidden from view (horizontal scrolling within the conversation view may be required)
• Resize the client window manually by dragging its corner
• Observe for multiple sources that during resizing, source abbreviations are elided at lower resolutions as shown in this GIF
• Click a few times on the square resize icon in the upper right corner
• Observe that the client switches back and forth between maximum size and your chosen size, with no part of the window hidden from view
• If a second monitor is available, move the client window to a second monitor and repeat the previous step
• Observe that the client switches back and forth between maximum size and your chosen size, with no part of the window hidden from view

Test case: Reply badges feature (Issue: freedomofpress/securedrop-client#76; PR: freedomofpress/securedrop-client#1142)

• Log into the SecureDrop Client and wait for it to sync.
• Observe that all previously sent replies show a two-letter badge representing the reply author. If first name and last name are set, lower-case initials will be used; otherwise, the first two letters of the username will be used.
• Send a reply.
• Observe that the sent reply shows a two-letter badge representing your account.
• Observe that the badge for replies you have sent is in a different color than the badge for replies sent by other users.
• Through the Journalist Interface, delete account X. (Stay logged into the JI for a later step.)
• Wait for the SecureDrop Client to synchronize with the server.
• Observe that replies sent by account X are now attributed to a placeholder user, represented by a star cluster icon.
• Through the Journalist Interface, change the first and last name of the user logged into the SecureDrop Client to names with different initial.
• Wait for the SecureDrop Client to synchronize with the server.
• Observe that the updated initials are shown in reply badges, and in the login badge (top left corner).
• Switch to offline mode
• Observe that all reply badges are still present, but are now in a uniform color, even if sent by the previously logged in user.

Test case: Decryption error styling (Issue: freedomofpress/securedrop-client#1150; PR: freedomofpress/securedrop-client#1151)

• Log out of the SecureDrop Client
• Via the Source Interface, send a message as a new source
• Via the Journalist Interface, send a reply to that source
• In sd-gpg, temporarily move ~/.gnupg to ~/.gnupg.bak to cause decryption errors
• Log into the SecureDrop Client and wait for it to sync
• Observe that message and reply are styled identically, in gray and italics: "cannot decrypt message" / "cannot decrypt reply"
• In sd-gpg, move ~/.gnupg.bak back to ~/.gnupg

Scenario: Investigating logs

Test case: Sorting logs by hostname (Issue: #583; PR: freedomofpress/securedrop-log#18)

• Observe that no host directory exists in ~/QubesIncomingLogs on sd-log (only relevant for "Fresh install" scenario, otherwise the directory will be present)
• Run the command logger LOGME in sd-app, sd-whonix, and sd-log.
• Observe that the line was added to ~/QubesIncomingLogs/sd-app and ~/QubesIncomingLogs/sd-whonix
• Observe that no sd-log directory exists in ~/QubesIncomingLogs on sd-log.

Scenario: Acceptance Tests

NOTES: The first time I tried this, I ran into this error (which I thought we had fixed): freedomofpress/securedrop-export#51. I will need to figure out what the STR is but basically I plugged in the printer and connected the cable to my Qubes laptop, clicked on "print" next to an attached document in the client, and sd-devices started for the first time, then I saw the error reported in this issue: freedomofpress/securedrop-export#51. To fix this I closed the client and unplugged the printer cable from the Qubes laptop and plugged it in again with a new cable, confirmed that it auto-attached to sd-devices properly, started the client, and printed successfully.

• When the user clicks Print on a downloaded submission:
  • a "Preparing to print..." message is displayed
  • the sd-devicesVM is started
  • the user is prompted to connect a supported printer
• When the user connects a printer, attaches it to the sd-devices VM, and clicks Continue:
  • a "Printing..." message is displayed
  • the X Printer Panel dialog is displayed with the printer selected
• When the user clicks Print in the X Printer Panel:
  • the submission is printed successflly.

[conorsch]

Release-specific test plan

Test parameters

• Hardware target: e.g. Thinkpad T490 20N20046US
• Install type: "happy path" upgrade
• securedrop-workstation-dom0-config version: 0.4.0 prod
• Release candidate version: 0.5.0-rc2

Scenario: Template consolidation:

Install Type 3: Sad Path Upgrade:

• Complete a production workstation setup following the installation instructions.
• Start the SecureDrop Client and Verify that its version in the login dialog footer is 0.2.1
• As the primary test journalist user, submit a reply to a source via the client.
• in a networked VM (work, say):
  • clone the https://github.com/freedomofpress/securedrop-workstation.git repo and ensure that it is on the main branch
• in dom0:
  • transfer the repo to dom0 using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
  • update the Salt config to use QA repos using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
  • remove the updater flag files, if they exist, with rm ~/.securedrop_launcher/sdw-{last_updated,update-status}
• Reboot the machine. When the GUI updater launches, leave it open without clicking Continue
• in dom0:
  • verify the config RPM version is 0.4.0.1-fc25, with dnf list securedrop-workstation-dom0-config
  • verify that the pre-consolidation templates are still in use via qvm-ls --tags sd-workstation
• In the updater, click Continue to start the update, and run tail -f ~/securedrop_launcher/logs/launcher.log in dom0
• Verify that the updater completes without error
  • required a reboot to complete, performed reboot when requested
• Verify that the client fails to start when the SecureDrop icon is double-clicked.
  • confirmed, and this was after reboot
• in dom0:
  • verify the config RPM version is now 0.5.0.*-fc25, with dnf list securedrop-workstation-dom0-config
  • update the Salt config to use QA repos using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
  • run sdw-admin --apply to apply the correct template configuration.
• Verify that the installation completes successfully.
• ❌ Verify that the client starts when the SecureDrop desktop icon is double-clicked, and its version is 0.2.1-dev-20201029-164632
  • The version was as expected, but the app icon did not immediately work. In order for the app icon to work, I had to reboot the entire machine. That's because sd-app was running, since the GUI updater ran on the previous boot, so the launcher logic tried to start the app (and failed, since the template was not properly configured).
• In dom0, run qvm-ls --tags sd-workstation, and verify that:
  • the only TemplateVMs listed are sd-(large|small)-buster-template) and securedrop-workstation-buster.
  • sd-app, sd-log, sd-proxy, and sd-gpg are based on sd-small-buster-template
  • sd-devices-dvm and sd-viewer are based on sd-large-buster-template
• Verify that client login and basic functionality are working.
• Perform a timed run of the updater via the dom0 command: time /opt/securedrop/launcher/sdw-launcher.py --skip-delta=0 and record the time here: * 7m5s

[eloquence]

• Hardware target: Thinkpad T480
• Install type: sad path upgrade
• securedrop-workstation-dom0-config version: 0.4.0 pre-upgrade
• Release candidate version: 0.5.0-rc2

Focused on exploratory MIME type testing to start with, since this is one of the highest risk areas that was modified in the consolidation.

• Correct MIME type lists are symlinked in sd-app and sd-viewer; xdg-open and nautilus behave as expected for each.
• Supported file types are opening correctly (tested .pdf, .docx, .png, .zip, .odt, .jpg for now); unsupported file types still attempt to open in disposable VM.

I am noticing that Nautilus offers ImageMagick as an option for images on sd-app, not sure if that was the case before, but may be worth removing from the small template if it's not needed? Note that ImageMagick has its own graphical viewer app.

[eloquence]

• Hardware target: Thinkpad T480
• Install type: sad path upgrade
• securedrop-workstation-dom0-config version: 0.4.0 pre-upgrade
• Release candidate version: 0.5.0-rc2

Login

• when SecureDrop desktop icon is double-clicked, preflight updater is displayed
• After preflight updater runs, when user clicks Continue, login dialog is displayed
• In login dialog:
  • show/hide password functionality works
  • incorrect password cannot log in
  • 2FA token reuse cannot log in after password failure
  • invalid 2FA token cannot log in
  • valid credentials and 2FA can log in

Sources

• after valid login:
  • the login dialog closes
  • source data is downloaded and source list is populated
  • user is prompted for GPG key access
  • submissions and replies are decrypted
  • the source list is displayed but no sources are selected by default
  • the conversation view is not populated
• when a source is selected in source list:
  • conversation view is populated with source conversation
  • a source message containing HTML is displayed as unformatted text
  • source submissions have an active Download button
  • source submission compressed file size is displayed accurately
• when the upper right 3-dot button is clicked:
  • a menu is displayed with a delete source account option
  • when delete source account is selected:
    • the source is deleted from the source list and the conversation view is blanked
    • the source is deleted from the server and not restored on next sync
    • source submissions and messages are removed from the client's data directory
• when a source is starred in source list, and the client is closed and reopened in Online mode:
  • the source is still starred in the source list

Replies

• when a source is selected in the source list:
  • the reply panel is available for use and there is no message asking the user to sign in
  • a reply can be added to the conversations
  • a reply containing HTML is displayed as unformatted text
  • a reply with a single string of characters longer than 100 chars is displayed correctly
  • ❌ a reply with a line longer than 100 chars is displayed correctly -- known issue, Tracking upstream issue QTBUG-85498 securedrop-client#815
  • two replies added immediately after each other are ordered correctly

[conorsch]

I am noticing that Nautilus offers ImageMagick as an option for images on sd-app

Checking on a 0.4.0 prod machine right now, I don't see ImageMagick as an option in the Nautilus right-click pane. I do see the package imagemagick marked as automatically installed in sd-app-buster-template, however, so the inclusion of the package isn't new. Frankly I'd prefer to remove nautilus, since we started including it before we had the client interface to handle submissions.

[conorsch]

I don't see ImageMagick as an option in the Nautilus right-click pane

Correction: if I right-click on an image file in sd-app on 0.4.0 prod, I see "Open With Open in Disposable VM" [sic] as the first and default option. If I choose "Open With Other Application," though, then the "Selection Application" dialog does indeed suggest ImageMagick. So definitely not a regression as part of 0.5.0. I don't propose we remove imagemagick from the small template right now, because it's automatically being installed—although I would like to trace what's including it.

[eloquence]

• Hardware target: Thinkpad T480
• Install type: sad path upgrade
• securedrop-workstation-dom0-config version: 0.4.0 pre-upgrade
• Release candidate version: 0.5.0-rc2

Submissions

Preview

• when Download is clicked on a submission:
  • the submission is downloaded and decrypted
  • the Download button is replaced with Print and Export options
  • the submission filename is displayed.
• For a DOC submission:
  • when the submission filename is clicked, a disposable VM (dispVM) is started.
  • after the dispVM starts, the submission is displayed in LibreOffice
  • when LibreOffice is closed, the dispVM shuts down
• For a PDF submission:
  • when the submission filename is clicked, a dispVM is started.
  • after the dispVM starts, the submission is displayed in evince
  • when evince is closed, the dispVM shuts down
• For a JPEG submission:
  • when the submission filename is clicked, a dispVM is started.
  • after the dispVM starts, the submission is displayed in Image Viewer
  • when Image Viewer is closed, the dispVM shuts down

Export

• When Export is first clicked on a submission:
  • the "Preparing to export..." message is displayed
  • the sd-devices VM is started
  • the user is prompted to insert an Export USB
  • On clicking Cancel, the prompt closes and the file is not exported
• When Export is clicked on the submission again:
  • the "Preparing to export..." message is displayed
  • the user is prompted to insert an Export USB
  • When the user inserts an invalid Export USB, attaches it to the sd-devices VM and clicks OK:
    • a message is displayed indicating that the Export USB is invalid and
      the user is prompted to insert a valid device
• When Export is clicked on the submission again:
  • the "Preparing to export..." message is displayed
  • the user is prompted to insert an Export USB
  • When the user inserts a valid Export USB, attaches it to the sd-devices VM, and clicks OK:
    • the user is prompted for the Export USB's password
  • When the user enters an invalid Export USB password and clicks Submit:
    • a failure message is displayed and the user is prompted to enter the password again
  • When the user enters an valid Export USB password and clicks Submit:
    • the file is saved to the Export USB
• When the user detaches the Export USB and mounts it on another VM or computer:
  • the decrypted submission is available in on the Export USB, in a directory sd-export-<timestamp>/export_data

Closing the client

• When the user clicks the main window close button:
  • the client exits.

[eloquence]

• Hardware target: Thinkpad T480
• Install type: sad path upgrade
• securedrop-workstation-dom0-config version: 0.4.0 pre-upgrade
• Release candidate version: 0.5.0-rc2

Scenario: Client and Journalist Interface both in use

Login

(skipped repopulating the client)

• when the JI address is visited in Tor Browser:
  • JI login page is displayed
• after valid login to JI using same account as for client:
  • sources page is displayed, containing the same sources as the client (order may differ)

Sources, replies, submissions

• when a source is starred in the client:
  • the source is also starred in the JI after a page reload
• when a starred source is unstarred in the JI:
  • the source is also unstarred in the client after next sync.
• when a reply is sent to a source via the client:
• the reply is visible in the JI and can be viewed by the source in the Source Interface
• when a reply is sent to a source via the JI:
  • the reply is visible in the source conversation view after next sync
• when the journalist account used to reply is deleted by an admin in the JI:
  • the next sync is successful
  • the reply is visible in the conversation view
  • ❌ the journalist's details are deleted from the client database - known issue, Deleted user is not fully removed from client database after a sync securedrop-client#1143
• when a reply is deleted by a source:
  • ❌ the reply is flagged as having being read in the client - not supported yet, Implement "read by source" receipts for journalist replies securedrop-client#889
• when an individual file submission is deleted in the JI:
  • the submission is no longer listed in the conversation view
  • the submission files are deleted from the client data directory
• when an individual message is deleted in the JI:
  • the message is no longer listed in the conversation view
  • the messages are deleted from the client database
• when a source is deleted in the JI:
  • the source is no longer listed in the client after next sync
  • files associated with the source are no longer present in the client data directory
• when a source is deleted in the client:
  • the source is no longer listed in the JI after a page reload

[zenmonkeykstop]

Still working thru the rest of the test plan, but on a fresh install the logging scenario is failing for me - specifically, logs are only showing up for sd-whonix and securedrop-workstation-buster.

[kushaldas]

Completed a happy-path upgrade on hardware.

Release-specific test plan

Test parameters

• Hardware target: e.g. Thinkpad T470
• Install type: "happy path" upgrade
• securedrop-workstation-dom0-config version: 0.4.0
• Release candidate version: 0.5.0-rc2

Scenario: Template consolidation:

Install Type 2: Happy Path Upgrade:

• Complete a production workstation setup following the installation instructions.
• Start the SecureDrop Client and Verify that its version in the login dialog footer is 0.2.1
• As the primary test journalist user, submit a reply to a source via the client.
• in a networked VM (work, say):
  • clone the https://github.com/freedomofpress/securedrop-workstation.git repo and ensure that it is on the main branch
• in dom0:
  • transfer the repo to dom0 using qvm-run --pass-io work "tar -c -C /home/user securedrop-workstation" | tar xvf -
  • update the Salt config to use QA repos using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
  • update the workstation config RPM via sudo qubes-dom0-update -y and verify that it is now the release candidate with dnf list securedrop-workstation-dom0-config
  • verify that the pre-consolidation templates are still in use via qvm-ls --tags sd-workstation
  • update the Salt config again, using sudo bash ~/securedrop-workstation/utils/qa-switch.sh
  • remove the updater flag files, if they exist, with rm ~/.securedrop_launcher/sdw-{last_updated,update-status}
• Double-click the SecureDrop icon to start the updater, and run tail -f ~/securedrop_launcher/logs/launcher.log in dom0
• Verify that the installation completes successfully.
• In dom0, run `qvm-ls --tags sd-workstation, and verify that:
  • the only TemplateVMs listed for AppVMs are sd-(large|small)-buster-template) and securedrop-workstation-buster.
  • sd-app, sd-log, sd-proxy, and sd-gpg are based on sd-small-buster-template
  • sd-devices-dvm and sd-viewer are based on sd-large-buster-template
• Perform a timed run of the updater via the dom0 command: time /opt/securedrop/launcher/sdw-launcher.py --skip-delta=0 and record the time here: 9m54s

Scenario: Use of sdw-admin

Test case: securedrop-admin to sdw-admin rename (Issue: #586; PR: #596)

• Observe that securedrop-admin can no longer be run in dom0
• Observe that you can now access the tool with sdw-admin in dom0
• Observe that sdw-admin --validate still functions as expected

Scenario: Investigating logs

Test case: Sorting logs by hostname (Issue: #583; PR: freedomofpress/securedrop-log#18)

• Observe that no host directory exists in ~/QubesIncomingLogs on sd-log (only relevant for "Fresh install" scenario, otherwise the directory will be present)
• Run the command logger LOGME in sd-app, sd-whonix, and sd-log.
• Observe that the line was added to ~/QubesIncomingLogs/sd-app and ~/QubesIncomingLogs/sd-whonix
• Observe that no sd-log directory exists in ~/QubesIncomingLogs on sd-log.

On a separate note for the client, can anyone please upload a markdown file (*.md) file as a source and try to view it as a client?

[eloquence]

• Hardware target: Thinkpad T480
• Install type: sad path upgrade
• securedrop-workstation-dom0-config version: 0.4.0 pre-upgrade
• Release candidate version: 0.5.0-rc2

Scenario: Offline mode without existing data

Offline to Online

• When SecureDrop desktop icon is double-clicked, preflight updater is displayed
• After preflight updater runs, when user clicks Continue, login dialog is displayed
• When user clicks Work Offline, login dialog closes and main window opens
• after startup:
  • there is no sync attempt with the server
  • the source list is empty
• When the user clicks the top-left user icon and chooses Sign in:
  • the login dialog is displayed over the main window
• When the user enters valid login details and clicks Log in:
  • the login dialog closes
  • The user icon is updated to reflect the user's details
  • the client is synced with the server and the source list is updated
• When the user selects a source with submissions from the source list:
  • the conversation view is populated with the source conversation
  • the reply panel is active
  • a reply can be sent to the source
  • a submission can be downloaded
  • a downloaded submission can be exported
• When the user clicks the main window close button:
  • the client exits.

Scenario: Offline mode with existing data

Offline to Online

• When SecureDrop desktop icon is double-clicked, preflight updater is displayed
• (Skipped updater run)
• When user clicks Work Offline, login dialog closes and main window opens
• after startup:
  • there is no sync attempt with the server
  • the source list is populated with contents of last server sync
• When the user selects a source with submissions from the source list:
  • the conversation view is populated with the source conversation
  • the reply panel is inactive, with a "Sign in" message
  • a previously downloaded submission can be exported
  • ❓ a previously downloaded submission can be printed no compatible printer
  • When the user clicks Download on an undownloaded submission, a message is displayed instructing the user to sign in to perform the download
• When the user clicks the top-left user icon and chooses Sign in:
  • the login dialog is displayed over the main window
• When the user enters valid login details and clicks Log in:
  • the login dialog closes
  • The user icon is updated to reflect the user's details
  • source data is synced with the server
• When the user selects a source with submissions from the source list:
  • the conversation view is populated with the source conversation
  • the reply panel is active
  • When the user replies to a source, the reply is added to the source conversation
  • When the user clicks Download on an undownloaded submission, the submission is downloaded and decrypted
  • When the user clicks Export on a submission, the export process can be completed
  • ❓ When the user clicks Print on a submission, the print process can be completed no compatible printer
• When the user clicks the main window close button:
  • the client exits.

[conorsch]

Performed a fresh install on rc3. Did not a few test failures, but they went away after an updater run and a reboot, see comment in #634 (comment)

Release-specific test plan

Test parameters

• Hardware target: Thinkpad T490 20N20046US
• Install type: fresh install
• securedrop-workstation-dom0-config version: 0.5.0-rc3
• Release candidate version: 0.5.0-rc3

Install Type 1: Fresh Install:

• Verify that the installation completes successfully.
• In dom0, run qvm-ls --tags sd-workstation, and verify that:
  • the only TemplateVMs listed are sd-(large|small)-buster-template) and securedrop-workstation-buster.
  • sd-app, sd-log, sd-proxy, and sd-gpg are based on sd-small-buster-template
  • sd-devices-dvm and sd-viewer are based on sd-large-buster-template

Scenario: Use of sdw-admin

Test case: securedrop-admin to sdw-admin rename (Issue: #586; PR: #596)

• Observe that securedrop-admin can no longer be run in dom0
• Observe that you can now access the tool with sdw-admin in dom0
• Observe that sdw-admin --validate still functions as expected

Scenario: Investigating logs

Test case: Sorting logs by hostname (Issue: #583; PR: freedomofpress/securedrop-log#18)

• Observe that no host directory exists in ~/QubesIncomingLogs on sd-log (only relevant for "Fresh install" scenario, otherwise the directory will be present)
• Run the command logger LOGME in sd-app, sd-whonix, and sd-log.
• Observe that the line was added to ~/QubesIncomingLogs/sd-app and ~/QubesIncomingLogs/sd-whonix
• Observe that no sd-log directory exists in ~/QubesIncomingLogs on sd-log.

[sssoleileraaa]

Since @conorsch already tested logging for the rc3 fresh install path on the same hardware that I have, I started to perform the sad path upgrade but ran into a setup issue (forgot to run sdw-admin --uninstall and then later make clean before installing 0.4.0 again) so the sad path scenario didn't go smoothly for me -- it was too happy of a path. Conor and I discussed how the rc3 fix has been thoroughly tested at this point so it makes the most sense to just set my workstation up with a fresh 0.4.0 prod install to prepare for testing the release as soon as it goes live tomorrow. I can even follow the same admin instructions we provide with the release.

[zenmonkeykstop]

Happy path failed for me - updater stalled indefinitely at 35%. Killed updater and reran it, it completed "successfully", updating all templateVMs but did not re-run sdw-admin --apply. This broke the logging setup (possibly what @emkll was seeing earlier?).

Ran sdw-admin --apply in dom0 , which corrected logging issues.

[emkll]

Release-specific test plan

Test parameters

• Hardware target: Thinkpad T490
• Install type: Fresh install
• securedrop-workstation-dom0-config version: 0.5.0-rc3
• Release candidate version: rc3

Install Type 1: Fresh Install:

• Verify that the installation completes successfully.
• In dom0, run qvm-ls --tags sd-workstation, and verify that:
  • the only TemplateVMs listed are sd-(large|small)-buster-template) and securedrop-workstation-buster.
  • sd-app, sd-log, sd-proxy, and sd-gpg are based on sd-small-buster-template
  • sd-devices-dvm and sd-viewer are based on sd-large-buster-template

Scenario: Use of sdw-admin

Test case: securedrop-admin to sdw-admin rename (Issue: #586; PR: #596)

• Observe that securedrop-admin can no longer be run in dom0
• Observe that you can now access the tool with sdw-admin in dom0
• Observe that sdw-admin --validate still functions as expected

Scenario: Investigating logs

Test case: Sorting logs by hostname (Issue: #583; PR: freedomofpress/securedrop-log#18)

• Observe that no host directory exists in ~/QubesIncomingLogs on sd-log (only relevant for "Fresh install" scenario, otherwise the directory will be present)
• Run the command logger LOGME in sd-app, sd-whonix, and sd-log.
• Observe that the line was added to ~/QubesIncomingLogs/sd-app and ~/QubesIncomingLogs/sd-whonix. Opened Make clean or sdw-admin --uninstall does not remove sd-rsyslog.conf in whonix-gw-15 #637 to track an issue where some config files remain on sd-whonix's template after uninstall
• Observe that no sd-log directory exists in ~/QubesIncomingLogs on sd-log.
  ❗ I did notice however that due to changes intoduced in Use qubesdb-read instead of gethostname securedrop-log#18, there are side effects to how dispvm logs are being managed: In the case of viewer VMs, they are assigned a random name. This means that for each VM started, it will create a new folder everytime. If I recall correctly, in the path, the DispVMs hostname would be that of its DispVM Template and would append DispVM logs to the same file/folder for all viewer DispVMs
  sd-rsyslog binary is working correctly and forwarding the files correctly, it seems to be the rsyslog configuration on the whonix vm

[kushaldas]

Printing on brother DCP 7065DN was smooth from client.

[emkll]

Tested the changes introduced in freedomofpress/securedrop-client#1184 using a production 0.2.1 client and database, reporting a successful migration of the draftreplies table to include correct journalist associations. I will push a new 0.3.0 tag to build production debs based on that revision

[emkll]

SecureDrop Workstation was released on 2020-11-09, closing