securedrop-client 0.2.0

[redshiftzero]

Description

If no issues are found with the latest securedrop-client nightly, 0.2.0 can be released along with its corresponding securedrop-proxy release: freedomofpress/securedrop-proxy#74

Test Plan

Test plan below is a draft added by @eloquence on 2020-05-07

Fix for #1033 (merged in #1045)

• Confirm that the baseline of filenames in the client is correctly aligned with Export/Print actions (i.e. this minor rendering issue should no longer occur)

Fix for #1042 (merged in #1043)

• Confirm that when performing the first sync of a client against a server with multiple sources, sources at the top of the list should have their messages and replies populated first. You should be able to see the progress of the sync as it works down through the source list.

Fix for #1053 (merged in #1057) and increased sync timeout (merged in #1055)

• Sync with a small number of sources to ensure that every 15 seconds you see an animation pulse. Test with a large number of sources (300+ range) to ensure that that long metadata syncs show a continuous sync animation.
• Confirm that there are no other regressions during these syncs.

Fix for #1030 (merged in #1058)

• Confirm that leading and trailing whitespace is trimmed from source messages and replies

Fix for #1052 (merged in #1063) and #1064 (merged in #1065)

• Confirm that you can select the contents of individual messages or replies with the mouse (left-click).
• Confirm that you can use standard keyboard shortcuts (Ctrl+C and Ctrl+V) to copy and paste these messages within sd-app
• Confirm that this can be used as a workaround for Tracking upstream issue QTBUG-85498 #815 by submitting a very long source string (e.g., 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789) and selecting it.
• Confirm that right-clicking in the Conversation View has no effect
• When testing with Permit whitelisting VMs for copy/paste & copying logs via tags securedrop-workstation#533 Confirm that you can copy the contents of messages or replies to a VM tagged with sd-receive-app-clipboard

Fix for #1060 (merged in #1069)

• Observe that the logs for downloaded messages, replies and files no contain empty strings, and that the folder names in the logs are correct
• Observe that the logs do not include sensitive original filenames (e.g., an uploaded file moscow.avi should not appear in the logs under that name after the file is downloaded in the client)

Fix for #140 (merged in #1059)

• (Re-)start the client
• Before logging in, in sd-gpg, run mv /home/user/.gnupg /home/user/.gnupg.save to delete the submission key.
• Log in.
• Confirm that messages and replies are gray and italic, containing decryption errors.
• Wait and watch the client log, confirming that messages and replies are never being retried because of the download failures.
• Back in sd-gpg, run rm -rf /home/user/.gnupg && cp -ax /home/user/.gnupg.save /home/user/.gnupg.
• Wait for the next sync; the failed downloads should not be retried and should not change their visual state, even though the key is now present.
• Restart the client. All the failed downloads should be retried, and the conversation views should update to normal status.

Fix for #1051 (merged in #1071)

• (Re-)start the client
• While the login screen is displayed, copy some string into the clipboard, e.g., "asdf" or your password
• Observe that the string you copied can be successfully pasted multiple times
• Log into the client
• Observe that the string you copied can no longer be pasted into the reply box
• Verify that the clipboard is also purged when switching into offline mode instead of logging in

Checklist

If these changes modify code paths involving cryptography, the opening of files in VMs or network (via the RPC service) traffic, Qubes testing in the staging environment is required. For fine tuning of the graphical user interface, testing in any environment in Qubes is required. Please check as applicable:

• I have tested these changes in the appropriate Qubes environment
• I do not have an appropriate Qubes OS workstation set up (the reviewer will need to test these changes)
• These changes should not need testing in Qubes
• These changes need testing in Qubes

If these changes add or remove files other than client code, the AppArmor profile may need to be updated. Please check as applicable:

• I have updated the AppArmor profile
• No update to the AppArmor profile is required for these changes
• I don't know and would appreciate guidance

If these changes modify the database schema, you should include a database migration. Please check as applicable:

• I have written a migration and upgraded a test database based on master and confirmed that the migration applies cleanly
• I have written a migration but have not upgraded a test database based on master and would like the reviewer to do so
• I need help writing a database migration
• No database schema changes are needed

[eloquence]

(Fleshing out test plan now based on git log 0.1.6..master.)

[eloquence]

I believe I've captured everything that's been merged since 0.1.6; feedback on draft test plan very much appreciated! Happy to curb level of detail or change organization in other ways. Note that this does not yet fully cover the RPM-level changes; see https://github.com/freedomofpress/securedrop-workstation/wiki/Workstation-Beta-Acceptance-Tests#securedrop-workstation-030 for a first outline of those.

[eloquence]

Some initial test results. In order to test, I switched my existing install (in all other respects currently configured in "production" mode) over to the securedrop-client and securedrop-proxy nightlies from apt-test.

Fix for #1033 (merged in #1045)

• Confirm that the baseline of filenames in the client is correctly aligned with Export/Print actions (i.e. this minor rendering issue should no longer occur)

Fix for #1042 (merged in #1043)

• Confirm that when performing the first sync of a client against a server with multiple sources, sources at the top of the list should have their messages and replies populated first.
  • First all source messages populate top to bottom, then all replies populate top to bottom.

Fix for #1053 (merged in #1057) and increased sync timeout (merged in #1055)

• Sync with a small number of sources to ensure that every 15 seconds you see an animation pulse.
• Test with a large number of sources (300+ range) to ensure that that long metadata syncs show a continuous sync animation.
  • Not done yet
• Confirm that there are no other regressions during these syncs.

Fix for #1030 (merged in #1058)

• Confirm that leading and trailing whitespace is trimmed from source messages and replies

Fix for #1052 (merged in #1063) and #1064 (merged in #1065)

• Confirm that you can select the contents of individual messages or replies with the mouse (left-click).
• Confirm that you can use standard keyboard shortcuts (Ctrl+C and Ctrl+V) to copy and paste these messages within sd-app
• Confirm that this can be used as a workaround for Tracking upstream issue QTBUG-85498 #815 by submitting a very long source string and selecting it.
• Confirm that right-clicking in the Conversation View has no effect
• When testing with Permit whitelisting VMs for copy/paste & copying logs via tags securedrop-workstation#533 Confirm that you can copy the contents of messages or replies to a VM tagged with sd-receive-app-clipboard
  • Not tested yet

Fix for #1060 (merged in #1069)

• Observe that the logs for downloaded messages, replies and files no contain empty strings, and that the folder names in the logs are correct
• Observe that the logs do not include sensitive original filenames (e.g., an uploaded file moscow.avi should not appear in the logs under that name after the file is downloaded in the client)

Fix for #140 (merged in #1059)

• (Re-)start the client
• Before logging in, in sd-gpg, run mv /home/user/.gnupg /home/user/.gnupg.save to delete the submission key.
• Log in.
• Confirm that messages and replies are gray and italic, containing decryption errors.
• Wait and watch the client log, confirming that messages and replies are never being retried because of the download failures.
• Back in sd-gpg, run rm -rf /home/user/.gnupg && cp -ax /home/user/.gnupg.save /home/user/.gnupg.
• Wait for the next sync; the failed downloads should not be retried and should not change their visual state, even though the key is now present.
• Restart the client. All the failed downloads should be retried, and the conversation views should update to normal status.

Fix for #1051 (merged in #1071)

• (Re-)start the client
• While the login screen is displayed, copy some string into the clipboard, e.g., "asdf" or your password
• Observe that the string you copied can be successfully pasted multiple times
• Log into the client
• Observe that the string you copied can no longer be pasted into the reply box
• Verify that the clipboard is also purged when switching into offline mode instead of logging in

[eloquence]

Observing that the production log errors in case of missing keys are pretty verbose, including tracebacks and fingerprints, in case there's interest in reducing the verbosity prior to release. Example logs:

[eloquence]

Will step through some of https://github.com/freedomofpress/securedrop-workstation/wiki/Workstation-Beta-Acceptance-Tests tomorrow to check for regressions.

[eloquence]

• Environment type: Qubes staging

• Client version: 20200520 nightly

• Workstation version: 0.3.0rc1

• Server version: 1.3.0, Qubes staging

• Test with a large number of sources (300+ range) to ensure that that long metadata syncs show a continuous sync animation.

• Confirm that you can copy the contents of messages or replies to a VM tagged with sd-receive-app-clipboard

Regarding sync behavior with a populated server, I've observed the following:

• A sync of 314 sources generated using qa_loader.py takes approximately 20 seconds.
• The animation finishes just after we see the results of the sync in the client log.
• During the initial sync, I've noticed the "Retrieving new messages" status gets displayed a couple of times instead of only once. I'm ignoring that for now (I'm curious if it is related to the duplication issue expected to be resolved via app: generic approach to prevent addition of duplicated api jobs #975?); ultimately we want that message and an animation to be displayed through the entire retrieval period.

[eloquence]

For regression testing I'll now take a stab at some of the scenarios in https://github.com/freedomofpress/securedrop-workstation/wiki/Workstation-Beta-Acceptance-Tests , starting with

Scenario: Online mode

Note: I still don't have a supported printer; for future test runs it would be super useful to have docs or 1:1 guidance on how to get an unsupported printer to work, if that's a reasonable proxy, so we don't all have to get Brother printers for basic regression testing (not that we've really made changes in this area, so not a huge priority for this time around).

[eloquence]

Environment type: Qubes staging
Client version: 20200522 nightly
Workstation version: 0.3.0rc1
Server version: Qubes staging 1.3.0

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 (known issue, Tracking upstream issue QTBUG-85498 #815)
  • a reply with a line longer than 100 chars is displayed correctly
  • two replies added immediately after each other are ordered correctly

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

[eloquence]

Environment type: Qubes staging
Client version: 20200522 nightly
Workstation version: 0.3.0rc1
Server version: Qubes staging 1.3.0

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

Print

Skipped due to lack of compatible printer, but also no expected impact from this release

Closing the client

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

[eloquence]

Focusing next on

Scenario: Client and Journalist Interface both in use

because we've previously seen several issues in this area and there have been some changes to sync behavior.

[eloquence]

Environment type: Qubes staging
Client version: 20200522 nightly
Workstation version: 0.3.0rc1
Server version: Qubes staging 1.3.0

Scenario: Client and Journalist Interface both in use

Prerequisites:

• server is available and contains source test data
• client data directory is empty

Login

• when SecureDrop desktop icon is double-clicked, preflight updater is displayed (updater not re-tested)
• After preflight updater runs, when user clicks Continue, login dialog is displayed
• after valid login to client:
  • the login dialog closes
  • source data is downloaded and source list is populated
  • user is prompted for GPG key access (previously granted)
  • submissions and replies are decrypted
  • the source list is displayed but no sources are selected by default
  • the conversation view is not populated
• 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

However, during this test, noticing a CPU spike and temporary client sluggishness in the late stage of the sync of ~350 sources, investigating a bit further.

[sssoleileraaa]

However, during this test, noticing a CPU spike and temporary client sluggishness in the late stage of the sync of ~350 sources, investigating a bit further.

There is a known issue and PR open that we can merge after this release (don't want it to be part of the release) that I think will address this issue, see #975 and #1095 (comment) for an explanation.

Other than that, it looks like tests are passing and we're ready to merge? No concerns on my end.

[kushaldas]

server: 1.3.0 prod vm
client: 0.1.6-dev-20200528-060128-buster

Fix for #1033 (merged in #1045)

• Confirm that the baseline of filenames in the client is correctly aligned with Export/Print actions (i.e. this minor rendering issue should no longer occur)

Fix for #1042 (merged in #1043)

• Confirm that when performing the first sync of a client against a server with multiple sources, sources at the top of the list should have their messages and replies populated first. You should be able to see the progress of the sync as it works down through the source list.

Fix for #1053 (merged in #1057) and increased sync timeout (merged in #1055)

• Sync with a small number of sources to ensure that every 15 seconds you see an animation pulse. Test with a large number of sources (300+ range) to ensure that that long metadata syncs show a continuous sync animation.
• Confirm that there are no other regressions during these syncs.

Fix for #1030 (merged in #1058)

• Confirm that leading and trailing whitespace is trimmed from source messages and replies

Fix for #1052 (merged in #1063) and #1064 (merged in #1065)

• Confirm that you can select the contents of individual messages or replies with the mouse (left-click).
• Confirm that you can use standard keyboard shortcuts (Ctrl+C and Ctrl+V) to copy and paste these messages within sd-app
• Confirm that this can be used as a workaround for Tracking upstream issue QTBUG-85498 #815 by submitting a very long source string (e.g., 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789) and selecting it.
• Confirm that right-clicking in the Conversation View has no effect
• [x When testing with https://github.com/Permit whitelisting VMs for copy/paste & copying logs via tags securedrop-workstation#533 Confirm that you can copy the contents of messages or replies to a VM tagged with sd-receive-app-clipboard (I could not copy file or text to/from) Update: All good, most probably I missed some step before

Fix for #1060 (merged in #1069)

• Observe that the logs for downloaded messages, replies and files no contain empty strings, and that the folder names in the logs are correct
• Observe that the logs do not include sensitive original filenames (e.g., an uploaded file moscow.avi should not appear in the logs under that name after the file is downloaded in the client)

Fix for #140 (merged in #1059)

• (Re-)start the client
• Before logging in, in sd-gpg, run mv /home/user/.gnupg /home/user/.gnupg.save to delete the submission key.
• Log in.
• Confirm that messages and replies are gray and italic, containing decryption errors.
• Wait and watch the client log, confirming that messages and replies are never being retried because of the download failures.
• Back in sd-gpg, run rm -rf /home/user/.gnupg && cp -ax /home/user/.gnupg.save /home/user/.gnupg.
• Wait for the next sync; the failed downloads should not be retried and should not change their visual state, even though the key is now present.
• Restart the client. All the failed downloads should be retried, and the conversation views should update to normal status.

Fix for #1051 (merged in #1071)

• (Re-)start the client
• While the login screen is displayed, copy some string into the clipboard, e.g., "asdf" or your password
• Observe that the string you copied can be successfully pasted multiple times
• Log into the client
• Observe that the string you copied can no longer be pasted into the reply box
• Verify that the clipboard is also purged when switching into offline mode instead of logging in