2.7.0 Test Plan

2.7.0 QA Checklist

For both upgrades and fresh installs, here is a list of functionality that requires testing. You can use this for copy/pasting into your QA report.

If you have submitted a QA report already for a release candidate with successful basic server testing and application acceptance testing sections, then you can skip these sections in subsequent reports, unless otherwise indicated by the Release Manager. This is to ensure that you focus your QA effort on the release-specific changes as well as changes since the previous release candidate.

Environment

• Install target:
• Tails version:
• Test Scenario:
• SSH over Tor:
• Release candidate:
• General notes:

Basic Server Testing

• After installing the testinfra dependencies, all tests in ./securedrop-admin verify are passing:
  • Install dependencies on Admin Workstation with cd ~/Persistent/securedrop && ./securedrop-admin setup -t
  • Run tests with ./securedrop-admin verify (this will take a while)
  • Remove test dependencies: rm -rf admin/.venv3/ && ./securedrop-admin setup
• QA Matrix checks pass

Command Line User Generation

• Can successfully add admin user and login

(Optional) Administration

• I have backed up and successfully restored the app server following the backup documentation
• If doing upgrade testing, make a backup on 2.6.0 and restore this backup on this release candidate
• "Send Test OSSEC Alert" button in the journalist triggers an OSSEC alert and an email is sent
• Can successfully add journalist account with HOTP authentication

(Optional) Application Acceptance Testing

Source Interface

Landing page base cases

• JS warning bar does not appear when using Security Slider high
• JS warning bar does appear when using Security Slider Low

First submission base cases

• On generate page, refreshing page produces a new 7-word codename
• On submit page, empty submissions produce flashed message
• On submit page, short message submitted successfully
• On submit page, file greater than 500 MB produces "The connection was reset" in Tor Browser quickly before the entire file is uploaded
• On submit page, file less than 500 MB submitted successfully

Returning source base cases

• Nonexistent codename cannot log in
• Empty codename cannot log in
• Legitimate codename can log in
• Returning user can view journalist replies - need to log into journalist interface to test

Journalist Interface

Login base cases

• Can log in with 2FA tokens
• incorrect password cannot log in
• invalid 2fa token cannot log in
• 2fa immediate reuse cannot log in
• Journalist account with HOTP can log in

Index base cases

• Filter by codename works
• Starring and unstarring works
• Click select all selects all submissions
• Selecting all and clicking "Download" works

Individual source page

• You can submit a reply and a flashed message and new row appears
• You cannot submit an empty reply
• Clicking "Delete Source Account" and the source and docs are deleted
• You can click on a document and successfully decrypt using application private key

Basic Tails Testing

After updating to this release candidate and running securedrop-admin tailsconfig

• The Updater GUI appears on boot

2.7.0 release-specific changes

Sequoia-related changes

(note that some of this overlaps with the "Basic Server Testing", there's no need to do it twice)

Fresh install

• Create a new source, make a submission that includes both a message and a file.
• Download the submission and successfully decrypt it with the journalist key
• Send a reply as a journalist
• Log in using SecureDrop Workstation, and successfully decrypt the message. (This also tests key exports over the API and GPG compat)
• Using SDW, confirm you can read the first journalist reply. Send another reply.
• Log in as the source, confirm you can read both journalist replies.
• bonus: on the app server run sudo -u www-data gpg --homedir /var/lib/securedrop/keys -k and verify no source keys exist (just the journalist public key).

Upgrade from 2.6.0 (few sources)

We focus on a few sources just to make it easier to keep track during QA, you could do this in combination with the next set below if you prefer.

• Fresh install of 2.6.0.
• Source A:
  • Create a source, and make a submission that includes both a message and a file.
  • On app server, run sudo -u www-data gpg --homedir /var/lib/securedrop/keys -k and verify your source's key is there
  • Send a journalist reply (via web, not SDW)
• Source B:
  • Create a source, and make a submission that includes bot ha message and a file.
  • Delete their GPG key pair, e.g. sudo -u www-data gpg --homedir /var/lib/securedrop/keys --yes --delete-secret-keys $fingerprint
  • Log in as journalist, try to send a reply but get an error they have no key pair yet.
• Source C:
  • Create a source, and make a submission that includes bot ha message and a file, then log out.
  • Log in as a journalist and send source C a reply
  • Delete Source C's GPG key pair, e.g. sudo -u www-data gpg --homedir /var/lib/securedrop/keys --yes --delete-secret-keys $fingerprint
  • Log in as journalist, try to send a reply but get an error they have no key pair yet.
  • Log in as source C and confirm that you get a Server Error page with the "look up a codename" form.
• Upgrade to 2.7.0.
• Source A:
  • Open the DB (sqlite3 /var/lib/securedrop/db.sqlite on app server) and run SELECT * FROM sources, verify your source's public key and fingerprint are there, but no secret key.
  • Log in as source, verify you can read the journalist reply
  • Re-run the same database query, verify the secret key is present now too.
  • On app server, run sudo -u www-data gpg --homedir /var/lib/securedrop/keys -k and verify your source's key is NOT there
  • As the source, submit another file + message
  • Successfully decrypt all files + messages as the journalist (using SDW is fine for this)
• Source B:
  • Open the DB, run SELECT * FROM sources and verify your source has no fingerprint, public key, nor secret key
  • Log in as journalist, confirm you still get an error they have no key pair yet.
  • Log in as the source
  • Open the DB again, run the same query and verify the source now has a fingerprint and key pair stored.
  • Switch back to journalist, see that you can now send replies. Send a reply!
  • As the source, read the journalist reply.
• Source C:
  • Open the DB, run SELECT * FROM sources and verify your source has no fingerprint, public key, nor secret key
  • Log in as journalist, confirm you still get an error they have no key pair yet.
  • Log in as the source, confirm that you can log in successfully
  • Open the DB again, run the same query and verify the source now has a fingerprint and key pair stored.
  • Switch back to journalist, see that you can now send replies. Send a reply!
  • As the source, read the journalist reply.

Upgrade from 2.6.0 (many sources)

• Fresh install of 2.6.0.
• On app server, cd /var/www/securedrop, then sudo -u www-data ./loaddata.py --source-count 10000
• Go and do something else while that finishes
• Open the DB (see previous instructions) and delete one source, e.g. DELETE FROM sources WHERE id=20 (dangling GPG key)
• Upgrade to 2.7.0, no errors.

Quieter OSSEC

• Configure OSSEC alerts.
• Leave your QA instance running for an extra day.
  • If you don't SSH into it that day, you should not receive a Daily report: Successful logins notification.
• Optional: On the Application Server, delete a submission from the database (via sqlite3, leaving it on the filesystem) and another from the filesystem (via rm, leaving it in the database).
  • At the end of the day, you should receive level-1 reports for rules 400800 and 400801.

Upgrade-only: Fail loudly on SHA1 submission key

• install 2.6.0 using a weak (RSA 1024bit) key for the Submission key
• verify that the installation completes successfully
• verify that submissions can be uploaded via the SI and downloaded via the JI
• upgrade to the latest RC:
  • on the Admin workstation: git checkout 2.7.0-rcN && ./securedrop-admin setup && ./securedrop-admin --force tailsconfig
  • follow the usual server upgrade procedure and verify no errors in the unattended-upgrades output
• Verify that the JI is unavailable after the upgrade reboot, and /var/log/apache2/journalist-error.log includes an error like "ERROR: Journalist public key is not valid:..."
• Verify that SI submissions fail.
• generate a strong (4096-bit RSA) key on the admin workstation and update the server configuration to use it with ./securedrop-admin --force sdconfig, then ./securedrop-admin --force install
• verify that the JI is available with no errors in logs
• verify that SI submissions succeed

Tails Workstations Ansible update

Fresh install

• After ./securedrop-admin setup verify that the Ansible version is 6.7.0 with eg. the command source admin/.venv3/bin/activate && pip list && deactivate
• Verify that playbooks run via other securedrop-admin commands (backup, restore, install) complete successfully.

Upgrade

• On the Admin Workstation currently set to use version 2.6.1 of the SecureDrop code, simulate a GUI update as follows:
  • cd Persistent/securedrop && git fetch && git checkout 2.7.0-rcN` (where N is the latest release candidate number)
  • ./securedrop-admin setup
    • Verify that this completes and you get an info-level message like "Ansible is out-of-date, removing it"
  • ./securedrop-admin --force tailsconfig
    • Verify that this completes successfully
• Verify that the Ansible version is now 6.7.0 with eg. the command source admin/.venv3/bin/activate && pip list && deactivate
• Verify that playbooks run via other securedrop-admin commands (backup, restore, install) complete successfully.

Preflight testing

Basic testing

• Install or upgrade occurs without error (from apt-qa.freedom.press per preflight procedure)
• Source interface is available and version string indicates it is 2.7.0
• A message can be successfully submitted

Tails

• The updater GUI appears on boot
• The update successfully occurs to 2.7.0
• After reboot, updater GUI no longer appears