Closed eloquence closed 4 years ago
Server: v2+v3 prod server running SecureDrop 1.2.1, using the v3 address in config.json
<>& '"
, TODO: test plan should be clarified)Found numerous problems around deletion and conversation view updating.
[x] Review default mime handler apps in sd-app:
user@sd-app:~$ for i in $(awk '{print $1}' /etc/mime.types | grep -v '#'); do xdg-mime query default $i; done | sort | uniq
display-im6.q16.desktop
gcr-viewer.desktop
open-in-dvm.desktop
org.gnome.Nautilus.desktop
thunderbird.desktop
vim.desktop
Images that would be opened locally with
display-im6.q16.desktop
:
image/pcx
image/x-icon
image/x-ms-bmp
image/x-rgb
image/x-xwindowdump
Certificate files that would be opened locally with
gcr-viewer.desktop
:
application/pkcs10: gcr-viewer.desktop
application/pkcs7-mime: gcr-viewer.desktop
application/pkix-cert: gcr-viewer.desktop
application/pkix-crl: gcr-viewer.desktop
application/x-x509-ca-cert: gcr-viewer.desktop
application/gzip
would be opened by
org.gnome.Nautilus.desktop
message/rfc822
would be opened by thunderbird.desktop
, but
thunderbird
segfaults
vim.desktop
would be used to open these, but vim is not
installed:
application/x-shellscript
text/english
text/x-c++hdr
text/x-chdr
text/x-c++src
text/x-csrc
text/x-java
text/x-makefile
text/x-moc
text/x-pascal
text/x-tcl
text/x-tex
sd-viewer
sd-viewer
qubes-run-terminal.desktop
. A viewer dispVM opened, a blank
light gray window covered the screen then disappeared, and the
dispVM halted. A terminal was not started, as far as I could
tell. Replacing vm-file-editor
in the viewer template with a
script containing a sleep, I could see no related process running
in the dispVM.High. Only signed macros from trusted sources are allowed to run. Unsigned macros are disabled.
lscpu
reports Thread(s) per core
== 1cat /sys/devices/system/cpu/smt/active
returns zerodmidecode -t processor
reports Core Count
and Thread Count
are equalPrerequisites:
- server is available and contains source test data
- access to sd-gpg keyring has not been previously granted
- client data directory is empty
- the
sd-devices
VM is not running (shut down manually if necessary)- a supported printer is available, but not attached.
- all VMs are up-to-date
NOTE: I had to increase the minimum memory allocated to sd-devices
to avoid cryptsetup operations being targeted by the OOM-killer. 1.5G seems reliable. Alternatively, @conorsch suggested bouncing qmemman
with sudo systemctl restart qubes-qmemman
if it had failed, which can be determined with the script in this comment.
When Export is first clicked on a submission:
sd-devices
VM is startedWhen Export is clicked on the submission again:
When Export is clicked on the submission again:
When the user detaches the Export USB and mounts it on another VM or computer:
sd-export-<timestamp>/export_data
sd-devices
VM is startedsd-devices
VM, and clicks Continue:
Prerequisites:
- server is available and contains source test data
- client data directory is empty
- the
sd-devices
VM is not running (shut down manually if necessary)- a supported printer is available, but not attached.
Prerequisites:
- server is available and contains source test data
- test data includes at least one previously downloaded submission
- test data includes at least one undownloaded submission
- client data directory has been synced with server in a previous login
- the
sd-devices
VM is not running (shut down manually if necessary)- a supported printer is available, but not attached.
Note: this scenario requires access to the Journalist Interface (JI) via Tor Browser. If the scenario is being tested on Qubes, the JI address can be found in
sd-whonix
in/usr/local/etc/torrc.d/50_user.conf
. Thesd-proxy
VM includes Tor Browser, and can be used to access the JI without config changes.Prerequisites:
- server is available and contains source test data
- client data directory is empty
when a source is starred in the client:
when a starred source is unstarred in the JI:
securedrop_client.logic:462(on_sync_failure) DEBUG: The SecureDrop server cannot be reached due to Error: (sqlite3.OperationalError) database is locked
[SQL: UPDATE sources SET last_updated=? WHERE sources.id = ?]
[parameters: ('2020-03-04 14:32:57.478957', 1)]
(Background on this error at: http://sqlalche.me/e/e3q8)
Syncs apparently stopped there. The client had to be restarted. Eventually the source was unstarred.
when a reply is sent to a source via the client:
when a reply is sent to a source via the JI:
when a reply is deleted by a source:
is_read
indicator.when an individual file submission is deleted in the JI:
[ ] the submission is no longer listed in the conversation view
:x: The export/print/filename widgets for the deleted submission are still visible on top of the first submission in the conversation view. This persists until the client is restarted.
:x: For a submission that had not been downloaded, nothing changes,
and clicking download on it crashes the client with
sqlalchemy.orm.exc.NoResultFound: No row was found for one()
[ ] the submission files are deleted from the client data directory
:x: No, again because of https://github.com/freedomofpress/securedrop-client/issues/856
when an individual message is deleted in the JI:
when a source is deleted in the JI:
when a source is deleted in the client:
I suggest we capture the configured server environment as well in these reports to make sure we have adequate coverage on testing with both v2 and v3 configurations. Just added that to my report.
the reply is flagged as having being read in the client :x: No, nothing changes. Replies don't have an is_read indicator.
This is in fact expected behavior, as this feature has not been implemented yet. However, I did not find an issue for it, so I added one: https://github.com/freedomofpress/securedrop-client/issues/889. I'll update the test plan on this point.
when an individual file submission is deleted in the JI:
the submission is no longer listed in the conversation view :x: The export/print/filename widgets for the deleted submission are still visible on top of the first submission in the conversation view. This persists until the client is restarted.
Was not able to reproduce for a single submission (it was removed from the conversation view as expected). Will now try with multiple.
^ I uploaded a new file as this source, after deleting the previous upload from the JI. That resulted in this state:
Note how the "Encrypted file on server" preview snippet appears, but there is no file widget. This is the corresponding JI state:
Submission 3 is the one that was deleted in the previous step. Will attempt a clean repro just on this behavior.
^ This is now tracked in https://github.com/freedomofpress/securedrop-client/issues/891. As noted there, the file widget is rendered correctly after a client restart, or after switching into offline mode by signing out.
- when an individual file submission is deleted in the JI:
- [ ] the submission files are deleted from the client data directory
- :x: No, again because of https://github.com/freedomofpress/securedrop-client/issues/856
I don't think this is due to https://github.com/freedomofpress/securedrop-client/issues/856 as I don't see any AppArmor denial in the logs. I've filed a separate issue for this in https://github.com/freedomofpress/securedrop-client/issues/892.
Thanks again @rmol for the detailed report. There are still more issues to be uncovered from it, but I also think we're reaching the point where a new release will help us have more confidence that QA results reflect the current state of the codebase.
Big shout-out to @zenmonkeykstop for the very thorough test plan that's helping us to uncover these issues.
Creating a new issue for QA reports about subsequent releases of RPM/Debian packages, cross-referencing this one.
This is an issue to track QA findings against beta release 0.2.2 (Debian packaging release 0.2.1) of the SecureDrop Workstation, dated 2020-02-03, using the provisional test plan as a starting point.