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 : https://github.com/freedomofpress/securedrop-workstation-prod-rpm-packages-lfs/pull/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.