Release SecureDrop Client 0.4.1 (alongside securedrop-export 0.2.5)

[eloquence]

This issue functions as a tracking ticket for the next point release of SecureDrop Client, version 0.4.1.

Release milestones

• Land pending changes
• Cut release branch
• Finalize test plan
• QA
• Production release

Included changes

The following PRs have landed or are still pending for a 0.4.1 release.

General

• scale source list and preview as window resizes #1211 - Scale source list and preview as window resizes
• scale conversation widgets as window resizes #1206 - Scale conversation widgets as window resizes

Still pending:

• Prevent event handler from being triggered twice #1220 - Prevent event handler from being triggered twice
• Additional code cleanup (WIP)

Development

• Update CODE_OF_CONDUCT.md #1216 - Update Code of Conduct
• Remove obsolete MIME setup in run.sh #1215 - Remove obsolete MIME setup in run.sh
• Update py to 1.10.0 for dev dependencies dependencies #1208 - Update py to 1.10.0 for dev dependencies dependencies
• Uses new reproducible wheels from our builds #1203 - Uses new reproducible wheels from our builds

Test plan

All tests should be performed against a release candidate build in a Qubes staging environment.

Release-specific changes

1. Ensure you have several source submissions on the server, including one source with multiple file submissions
2. Log into the SecureDrop Client and wait for it to sync

• Observe that the SecureDrop Client window is maximized

4. Select a source with multiple files
5. Ensure that one of the files is downloaded and another is still awaiting download
6. Resize the client by manually dragging the client handle back and forth

• Observe that the preview snippets in the source list, conversation bubbles, and file placeholders scale according to your window size

7. Resize the client to its smallest possible size and switch between different sources

• Observe that no part of the conversation view requires horizontal scrolling

8. Open a downloaded file in a disposable VM

• Observe that Files are opened twice #1217 is fixed and only a single disposable VM is opened

9. Pause your sd-whonix VM
10. Send a reply
11. Sign out of the client

• Observe that the reply transitioned to "Failed to send" state
• Observe that you still do not need to scroll horizontally at the smallest window size

12. Unpause your sd-whonix VM

[eloquence]

Added a test plan draft for the release-specific changes - @creviera, would appreciate if you could take a quick look.

[sssoleileraaa]

I think this looks good. We just need to make sure that we run through the test plan being tracked outside of this issue for the "additional code cleanup" and then we should be complete.

[eloquence]

Simplified end-to-end testing

• Syncing from scratch works
• Sending a reply works
• Downloading and opening files of different types in disposable VMs works
• Deleting sources in the SecureDrop Client works
• Deleting sources in the Journalist Interface and having the client pick it up works
• Deleting individual files in Journalist Interface and having the client pick up the changes works
• Replying via Journalist Interface and picking up replies within the client works
• Seen/unseen at the source level (AKA read/unread) works
• Changing seen/unseen state in SecureDrop Client changes it in Journalist Interface and vice versa
• Export to USB works
• Print dialog opens and shows expected error message (print itself not tested)

Release-specific changes

1. Ensure you have several source submissions on the server, including one source with multiple file submissions
2. Log into the SecureDrop Client and wait for it to sync

• Observe that the SecureDrop Client window is maximized

4. Select a source with multiple files
5. Ensure that one of the files is downloaded and another is still awaiting download
6. Resize the client by manually dragging the client handle back and forth

• Observe that the preview snippets in the source list, conversation bubbles, and file placeholders scale according to your window size

7. Resize the client to its smallest possible size and switch between different sources

• Observe that no part of the conversation view requires horizontal scrolling

8. Open a downloaded file in a disposable VM

• Observe that Files are opened twice #1217 is fixed and only a single disposable VM is opened

9. Pause your sd-whonix VM
10. Send a reply
11. Sign out of the client

• Observe that the reply transitioned to "Failed to send" state
• Observe that you still do not need to scroll horizontally at the smallest window size

12. Unpause your sd-whonix VM

[eloquence]

Configuration:

• workstation: Qubes 4.0.4 / SecureDrop Workstation staging with 20210317 nightlies
• server: PDX1 server; NUC10 hardware running SecureDrop 1.8.0 on Ubuntu 20.04 ✨

Simplified end-to-end testing

• Syncing from scratch works
• Sending a reply works
• Downloading and opening files of different types in disposable VMs works
• Deleting sources in the SecureDrop Client works
• Deleting sources in the Journalist Interface and having the client pick it up works
• Deleting individual files in Journalist Interface and having the client pick up the changes works
• Replying via Journalist Interface and picking up replies within the client works
• Seen/unseen at the source level (AKA read/unread) works
• Changing seen/unseen state in SecureDrop Client changes it in Journalist Interface and vice versa
• Export to USB works (:exclamation: saw https://github.com/freedomofpress/securedrop-export/issues/66 a couple of times)
• Print dialog opens and shows expected error message (print itself not tested)

Release-specific changes

1. Ensure you have several source submissions on the server, including one source with multiple file submissions
2. Log into the SecureDrop Client and wait for it to sync

• Observe that the SecureDrop Client window is maximized

4. Select a source with multiple files
5. Ensure that one of the files is downloaded and another is still awaiting download
6. Resize the client by manually dragging the client handle back and forth

• Observe that the preview snippets in the source list, conversation bubbles, and file placeholders scale according to your window size

7. Resize the client to its smallest possible size and switch between different sources

• Observe that no part of the conversation view requires horizontal scrolling

8. Open a downloaded file in a disposable VM

• Observe that Files are opened twice #1217 is fixed and only a single disposable VM is opened

9. Pause your sd-whonix VM
10. Send a reply
11. Sign out of the client

• Observe that the reply transitioned to "Failed to send" state
• Observe that you still do not need to scroll horizontally at the smallest window size

12. Unpause your sd-whonix VM

Ensure no FileNotFoundError regression that crashes the app

• rm -r ~/.securedrop_client
• start the client and download a file that had been downloaded before you deleted ~/.securedrop_client
• Ensure the client does not crash with a FileNotFoundError

Ensure sanitized sources

• Either edit the malicious server script to inject the sources enpoint or do what I did below (easier even though the server should never get into this state)
• Start the client
• Open db.sqlite on the server
• Update the sources table so that one of the sources has an injected path traversal name, e.g.

  update sources
  set journalist_designation = "../../../../../../../INJECTED"
  where id = 3; 

• Confirm that the source disappears from the client GUI
• While you're at it, do this for a file, reply, and message and verify that each item gracefully disappears from the client GUI
• They also come back! ;-)

Ensure minimal perms

Verify default behavior

• create a new source and download a file from that source via the client
• cd to the <sdc-home>/data directory
• ls -la and verify that the source name directory for the new source has the following permissions: drwx------
• ls -la <source-name> and verify that the submission directory has the following permissions still: drwx------
• ls -la <source-name>/<submission-directory> and verify that the submission itself has the following permissions: -rw-------

Verify Unsafe Permissions Error

• Create a new source and send a file from that source
• cd <sdc_home>/data and create the source name directory and submission directory with insecure permissions (777)
• Try to download the submission that matches the submission directory name (e.g. 3-<source-name>-doc)
• ❌ Verify that you see an error in the client and an error log about the unsafe file permissions. You should not be able to download into an unsafe directory.

I did not see an error (including in the logs) -- instead the directories were quietly changed to the correct permissions before the file was downloaded.

Verify we don't crash if source-name directory has 755 perms

• Since we're not including a fix for the 755 bug, test the following:
• Download a file from the current version of the client on main
• ls -la <source-name> and verify that the submission directory has the following permissions still: drwxr-xr-x
• Now close the client and run the client from this PR
• Click on the source with the downloaded file and confirm the client continues to show the file as downloaded

[eloquence]

tl;dr: No significant issues but one observed difference from the test plan in how downloading to unsafe directories was handled.

As discussed, we can investigate export issue further post-release as we can't clearly attribute it to any changes in this release (and it's a bit annoying but not critical). Given that it also goes via the sd-devices path, I would suggest that we re-test print as well soon (I can't do so as I don't have a supported printer).

[sssoleileraaa]

❌ Verify that you see an error in the client and an error log about the unsafe file permissions. You should not be able to download into an unsafe directory.

I forgot to update the test plan. We now update the unsafe dir to the proper perms to gracefully handle the old 755 journalist_designation dirs in the data_dir. So you should now expect the perms to change and for the download to be successful.

[emkll]

securedrop-client 0.4.1 and securedrop-export 0.2.5 were released on March 17th 2021 (see https://github.com/freedomofpress/securedrop-debian-packages-lfs/pull/46), closing.