Release SecureDrop 2.0.0

[zenmonkeykstop]

This is a tracking issue for the release of SecureDrop 2.0.0

Tentatively scheduled as follows:

String and feature freeze: 2021-06-08
String comment period: 2021-06-08 - 2021-06-11
Translation period: 2021-06-11 - 2021-06-21
Pre-release announcement: 2021-06-15
Release date: ~2021-06-22

Release manager: @zenmonkeykstop
Deputy release manager: @kushaldas
Localization manager: @rmol
Deputy localization manager: @kushaldas
Communications manager:: @rocodes

SecureDrop maintainers and testers: As you QA 2.0.0, please report back your testing results as comments on this ticket. File GitHub issues for any problems found, tag them "QA: Release", and associate them with the 2.0.0 milestone for tracking (or ask a maintainer to do so).

Test debian packages will be posted on https://apt-test.freedom.press signed with the test key. An Ansible playbook testing the upgrade path is here.

QA Matrix for 2.0.0

Test Plan for 2.0.0

Prepare release candidate (2.0.0~rc1)

• Link to latest version of Tails, including release candidates, to test against during QA
• Fetch Tor 0.4.5.8 (latest stable) packages and deploy to apt-test server
• Prepare 2.0.0~rc1 release changelog
• Branch off release/2.0.0 from develop
• Prepare 2.0.0~rc1
• Build debs, preserving build log, and put up 2.0.0~rc1 on test apt server
• Commit build log.

Prepare release candidate (2.0.0~rc2)

• Prepare 2.0.0~rc2 release changelog
• Prepare 2.0.0~rc2
• Build debs, preserving build log, and put up 2.0.0~rc2 on test apt server
• Commit build log.

Prepare release candidate (2.0.0~rc3)

• Prepare 2.0.0~rc3 release changelog
• Prepare 2.0.0~rc3
• Build debs, preserving build log, and put up 2.0.0~rc3 on test apt server
• Commit build log.

Prepare release candidate (2.0.0~rc4)

• Prepare 2.0.0~rc4 release changelog
• Prepare 2.0.0~rc4
• Build debs, preserving build log, and put up 2.0.0~rc4 on test apt server
• Commit build log.

Prepare release candidate (2.0.0~rc5)

• Prepare 2.0.0~rc5 release changelog
• Prepare 2.0.0~rc5
• Build debs, preserving build log, and put up 2.0.0~rc5 on test apt server
• Commit build log.

After each test, please update the QA matrix and post details for Basic Server Testing, Application Acceptance Testing and 1.8.0-specific testing below in comments to this ticket.

Final release

• Ensure builder in release branch is updated and/or update builder image
• Push signed tag
• Pre-Flight: Test updater logic in Tails (apt-qa tracks the release branch in the LFS repo)
• Build final Debian packages for 2.0.0 (and preserve build log)
• Commit package build log to https://github.com/freedomofpress/build-logs
• Upload Debian packages to apt-qa server (including Tor 0.4.5.8 packages)
• Pre-Flight: Test that install and upgrade from 1.8.2 to 2.0.0 works w/ prod repo debs (apt-qa.freedom.press polls the release branch in the LFS repo for the debs)
• Flip apt QA server to prod status (merge to main in the LFS repo)
• Merge Docs branch changes to main and verify new docs build in securedrop-docs repo
• Prepare release messaging

Post release

• Create GitHub release object
• Once release object is created, update versions in securedrop-docs and Wagtail
• Build readthedocs and verify new docs show up on https://docs.securedrop.org
• Publish announcements
• Merge changelog back to develop
• Update roadmap wiki page: https://github.com/freedomofpress/securedrop/wiki/Development-Roadmap

[zenmonkeykstop]

2.0.0 QA Checklist - VMs

Environment

• Install target: prod vms
• Tails version: 4.19
• Test Scenario: fresh
• SSH over Tor: yes
• Release candidate: rc1
• General notes: (Installer broken thanks to [2.0.0-rc1] Tails environment validation fails on first installer run #5989 - manually patched)

Basic Server Testing

• I can access both the source and journalist interfaces
• I can SSH into both machines over Tor
• AppArmor is loaded on app
  • 0 processes are running unconfined
• AppArmor is loaded on mon
  • 0 processes are running unconfined
• Both servers are running grsec kernels
• iptables rules loaded
• OSSEC emails begin to flow after install
• OSSEC emails are decrypted to correct key and I am able to decrypt them
• 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

Administration

• I have backed up and successfully restored the app server following the backup documentation
• If doing upgrade testing, make a backup on 1.8.2 and restore this backup on this release candidate N/A
• "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 not tested

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 codename 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
• Updating occurs without issue

2.0.0 release-specific changes

• Removed support for v2 service configuration #5915

  • during sdconfig, there are no prompts to choose either v2 or v3 services
  • after installation, only v3 services are referenced in /etc/tor/torrc for app and mon
  • only v3 services are defined under /var/lib/tor/services - sourcev3 and journalistv3 for app, and sshv3 for app and mon if SSH-over-tor is enabled.

• Updated Tor to 0.4.5.8 #5971

  • Tor package versions are 0.4.5.8 on both app and mon

• Removed flag-for-reply #5954

  • Create a new source via the Source Interface (SI) and submit a message. Note the codename.
  • in the Journalist Interface (JI), go to the source's individual listing page and confirm that reply functionality is available with a message displayed starting with "You can write a secure reply...". Note their journalist designation.
  • Log into the app server and find the source's filesystem_id either directly or via the command (as the www-data user:

    sqlite3 /var/lib/securedrop/db.sqlite "select filesystem_id from sources where journalist_designation = '<journalist designation>'"
    

  • Delete the source's reply keys with the commands (as www-data):

    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-secret-keys FILESYSTEM_ID
    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-keys FILESYSTEM_ID
    

  • Purge the redis cache (as root) with: redis-cli del sd/crypto-util/fingerprints
  • in the JI, reload the individual source page and confirm that replies are disabled, with a message displayed starting with "This source has no encryption keys..."
  • in the SI, log back in as the same source and submit a message
  • in the JI, reload the source's individual listing page and confirm that reply functionality is available again, with a message displayed starting with "You can write a secure reply...". Note their journalist designation.

• Removed v2 field from metadata endpoint #5926

  • Visit the http://<source interface>/metadata endpoint and confirm that the source_v2_url field is not displayed and the source_v3_url address is displayed and has the correct value.

• Store directory is recreated if missing for an existing source #5944

  • Create a source on the SI and submit one or more messages. Note the codename
  • In the JI, delete the source's files and messages while preserving the source account. Note their journalist designation
  • Log into the app server, identify the filesystem ID for the source, and delete the directory /var/lib/securedrop/store/<filesystem ID>
  • Log back into the SI as the source and submit a message, confirm that the submission completes successfully
  • Verify that the message can be downloaded via the JI

• Missing file error message text update #5905

  • Create a source in the SI and submit a message
  • Log in to the app server and delete the encrypted message file corresponding to the submission
  • Log in to the JI, go to the source's individual listing page, and attempt to download the message
  • Confirm that an error message is displayed starting with: "Your download failed because the file could not be found."

• invalid image error message text update #5932

  • Log into the app server, note existing permissions on the /var/www/securedrop/static/i directory, and change them via chmod 555 /var/www/securedrop/static/i
  • Log into the JI and attempt to upload a PNG logo image
  • Verify that the upload fails and the error message includes the word "Please."
  • return the changed directory permissions to their original value

• Logo image served as static resource #5874

  • Visit the SI and JI and verify that on both, the logo image URL path component is i/logo.png
  • On the JI, upload a custom logo, and verify that the SI and JI both display the new custom logo, with URL path component i/custom_logo.png

• /sources/<uuid>/conversation endpoint deletes source files while retaining source account #5963

  • in the JI, delete all sources.
  • in the SI, create 3 sources all with multiple files and messages
  • Download this test script to the Admin workstation, edit the script to add in the JI address and journalist account details for your instance, then follow the instructions to run it
  • Confirm that the script runs successfully
  • in the JI, confirm that the files and messages for the second source are deleted, while the other two are preserved.

• upload-screenshots.py removed from application package #5941

  • log into the application server and confirm that the file /var/www/securedrop/upload-screenshots.py is not present.

• Jounalist workstation can be configured without tor_v3_keys.json being present #5965

  • Confirm that a new journalist workstation can be provisioned using only the app-sourcev3-ths and app-journalist.auth_private files from the Admin Workstation, and that no errors about tor_v3_keys.json are obverved during the tailsconfig command on the new workstation. deferred to rc2 due to changes in fix: updated validate role to skip journalist auth check on fresh installs #5990

Preflight testing

Basic testing

• Install or upgrade occurs without error
• Source interface is available and version string indicates it is 2.0.0
• A message can be successfully submitted

Tails

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

[kushaldas]

2.0.0 QA Checklist - VMs

Environment

• Install target: prod vms
• Tails version: 4.19
• Test Scenario: Update from 1.8.2
• SSH over Tor: yes
• Release candidate: rc1
• General notes: None

Basic Server Testing

• I can access both the source and journalist interfaces
• I can SSH into both machines over Tor
• AppArmor is loaded on app
  • 0 processes are running unconfined
• AppArmor is loaded on mon
  • 0 processes are running unconfined
• Both servers are running grsec kernels
• iptables rules loaded
• OSSEC emails begin to flow after install
• OSSEC emails are decrypted to correct key and I am able to decrypt them
• 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

Administration

• I have backed up and successfully restored the app server following the backup documentation
• If doing upgrade testing, make a backup on 1.8.2 and restore this backup on this release candidate N/A
• "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 not tested

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 codename 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
• Updating occurs without issue

2.0.0 release-specific changes

• Removed support for v2 service configuration #5915

  • during sdconfig, there are no prompts to choose either v2 or v3 services
  • after installation, only v3 services are referenced in /etc/tor/torrc for app and mon
  • only v3 services are defined under /var/lib/tor/services - sourcev3 and journalistv3 for app, and sshv3 for app and mon if SSH-over-tor is enabled.

• Updated Tor to 0.4.5.8 #5971

  • Tor package versions are 0.4.5.8 on both app and mon

• Removed flag-for-reply #5954

  • Create a new source via the Source Interface (SI) and submit a message. Note the codename.
  • in the Journalist Interface (JI), go to the source's individual listing page and confirm that reply functionality is available with a message displayed starting with "You can write a secure reply...". Note their journalist designation.
  • Log into the app server and find the source's filesystem_id either directly or via the command (as the www-data user:

    sqlite3 /var/lib/securedrop/db.sqlite "select filesystem_id from sources where journalist_designation = '<journalist designation>'"
    

  • Delete the source's reply keys with the commands (as www-data):

    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-secret-keys FILESYSTEM_ID
    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-keys FILESYSTEM_ID
    

  • Purge the redis cache (as root) with: redis-cli del sd/crypto-util/fingerprints
  • in the JI, reload the individual source page and confirm that replies are disabled, with a message displayed starting with "This source has no encryption keys..."
  • in the SI, log back in as the same source and submit a message
  • in the JI, reload the source's individual listing page and confirm that reply functionality is available again, with a message displayed starting with "You can write a secure reply...". Note their journalist designation.

• Removed v2 field from metadata endpoint #5926

  • Visit the http://<source interface>/metadata endpoint and confirm that the source_v2_url field is not displayed and the source_v3_url address is displayed and has the correct value.

• Store directory is recreated if missing for an existing source #5944

  • Create a source on the SI and submit one or more messages. Note the codename
  • In the JI, delete the source's files and messages while preserving the source account. Note their journalist designation
  • Log into the app server, identify the filesystem ID for the source, and delete the directory /var/lib/securedrop/store/<filesystem ID>
  • Log back into the SI as the source and submit a message, confirm that the submission completes successfully
  • Verify that the message can be downloaded via the JI

• Missing file error message text update #5905

  • Create a source in the SI and submit a message
  • Log in to the app server and delete the encrypted message file corresponding to the submission
  • Log in to the JI, go to the source's individual listing page, and attempt to download the message
  • Confirm that an error message is displayed starting with: "Your download failed because the file could not be found."

• invalid image error message text update #5932

  • Log into the app server, note existing permissions on the /var/www/securedrop/static/i directory, and change them via chmod 555 /var/www/securedrop/static/i
  • Log into the JI and attempt to upload a PNG logo image
  • Verify that the upload fails and the error message includes the word "Please."
  • return the changed directory permissions to their original value

• Logo image served as static resource #5874

  • Visit the SI and JI and verify that on both, the logo image URL path component is i/logo.png
  • On the JI, upload a custom logo, and verify that the SI and JI both display the new custom logo, with URL path component i/custom_logo.png

• /sources/<uuid>/conversation endpoint deletes source files while retaining source account #5963

  • in the JI, delete all sources.
  • in the SI, create 3 sources all with multiple files and messages
  • Download this test script to the Admin workstation, edit the script to add in the JI address and journalist account details for your instance, then follow the instructions to run it
  • Confirm that the script runs successfully
  • in the JI, confirm that the files and messages for the second source are deleted, while the other two are preserved.

• upload-screenshots.py removed from application package #5941

  • log into the application server and confirm that the file /var/www/securedrop/upload-screenshots.py is not present.

• Jounalist workstation can be configured without tor_v3_keys.json being present #5965

  • Confirm that a new journalist workstation can be provisioned using only the app-sourcev3-ths and app-journalist.auth_private files from the Admin Workstation, and that no errors about tor_v3_keys.json are obverved during the tailsconfig command on the new workstation. deferred to rc2 due to changes in fix: updated validate role to skip journalist auth check on fresh installs #5990

Preflight testing

Basic testing

• Install or upgrade occurs without error
• Source interface is available and version string indicates it is 2.0.0
• A message can be successfully submitted

Tails

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

[kushaldas]

I did fresh install on 2.0.0-rc2 couple of time with #5990 in mind. By keeping all the ths and private key files, and after removing all of those files.

[rocodes]

2.0.0 QA Checklist

Environment

• Install target: NUC7i7DNHE
• Tails version: 4.19
• Test Scenario: clean install
• SSH over Tor: yes
• Release candidate: rc2
• General notes:

Basic Server Testing

• I can access both the source and journalist interfaces
• I can SSH into both machines over Tor
• AppArmor is loaded on app
  • 0 processes are running unconfined
• AppArmor is loaded on mon
  • 0 processes are running unconfined
• Both servers are running grsec kernels
• iptables rules loaded
• OSSEC emails begin to flow after install
• OSSEC emails are decrypted to correct key and I am able to decrypt them
• [:x:] 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
  • Note: see QA matrix regarding the failures
• [:x:] QA Matrix checks pass
  See notes in QA Matrix

Command Line User Generation

• Can successfully add admin user and login

Administration

• I have backed up and successfully restored the app server following the backup documentation Not tested
• If doing upgrade testing, make a backup on 1.8.2 and restore this backup on this release candidate Not tested
• "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

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 codename 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 Not yet tested

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
• Updating occurs without issue

2.0.0 release-specific changes

• Removed support for v2 service configuration #5915

  • during sdconfig, there are no prompts to choose either v2 or v3 services
  • after installation, only v3 services are referenced in /etc/tor/torrc for app and mon
  • only v3 services are defined under /var/lib/tor/services - sourcev3 and journalistv3 for app, and sshv3 for app and mon if SSH-over-tor is enabled.

• Updated Tor to 0.4.5.8 #5971

  • Tor package versions are 0.4.5.8 on both app and mon

• Removed flag-for-reply #5954

  • Create a new source via the Source Interface (SI) and submit a message. Note the codename.
  • in the Journalist Interface (JI), go to the source's individual listing page and confirm that reply functionality is available with a message displayed starting with "You can write a secure reply...". Note their journalist designation.
  • Log into the app server and find the source's filesystem_id either directly or via the command (as the www-data user:

    sqlite3 /var/lib/securedrop/db.sqlite "select filesystem_id from sources where journalist_designation = '<journalist designation>'"
    

  • Delete the source's reply keys with the commands (as www-data):

    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-secret-keys FILESYSTEM_ID
    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-keys FILESYSTEM_ID
    

  • Purge the redis cache (as root) with: redis-cli del sd/crypto-util/fingerprints
  • in the JI, reload the individual source page and confirm that replies are disabled, with a message displayed starting with "This source has no encryption keys..."
  • in the SI, log back in as the same source and submit a message
  • in the JI, reload the source's individual listing page and confirm that reply functionality is available again, with a message displayed starting with "You can write a secure reply...". Note their journalist designation.

• Removed v2 field from metadata endpoint #5926

  • Visit the http://<source interface>/metadata endpoint and confirm that the source_v2_url field is not displayed and the source_v3_url address is displayed and has the correct value.

• Store directory is recreated if missing for an existing source #5944

  • Create a source on the SI and submit one or more messages. Note the codename
  • In the JI, delete the source's files and messages while preserving the source account. Note their journalist designation
  • Log into the app server, identify the filesystem ID for the source, and delete the directory /var/lib/securedrop/store/<filesystem ID>
  • Log back into the SI as the source and submit a message, confirm that the submission completes successfully
  • Verify that the message can be downloaded via the JI

• Missing file error message text update #5905

  • Create a source in the SI and submit a message
  • Log in to the app server and delete the encrypted message file corresponding to the submission
  • Log in to the JI, go to the source's individual listing page, and attempt to download the message
  • Confirm that an error message is displayed starting with: "Your download failed because the file could not be found."

• invalid image error message text update #5932

  • Log into the app server, note existing permissions on the /var/www/securedrop/static/i directory, and change them via chmod 555 /var/www/securedrop/static/i
  • Log into the JI and attempt to upload a PNG logo image
  • Verify that the upload fails and the error message includes the word "Please."
  • return the changed directory permissions to their original value

• Logo image served as static resource #5874

  • Visit the SI and JI and verify that on both, the logo image URL path component is i/logo.png
  • On the JI, upload a custom logo, and verify that the SI and JI both display the new custom logo, with URL path component i/custom_logo.png

• /sources/<uuid>/conversation endpoint deletes source files while retaining source account #5963

  • in the JI, delete all sources.
  • in the SI, create 3 sources all with multiple files and messages
  • Download this test script to the Admin workstation, edit the script to add in the JI address and journalist account details for your instance, then follow the instructions to run it
  • Confirm that the script runs successfully
  • in the JI, confirm that the files and messages for the second source are deleted, while the other two are preserved.

• upload-screenshots.py removed from application package #5941

  • log into the application server and confirm that the file /var/www/securedrop/upload-screenshots.py is not present.

• Jounalist workstation can be configured without tor_v3_keys.json being present #5965

  • [:x:] Confirm that a new journalist workstation can be provisioned using only the app-sourcev3-ths and app-journalist.auth_private files from the Admin Workstation, and that no errors about tor_v3_keys.json are obverved during the tailsconfig command on the new workstation. See [2.0.0-rc2] Failure during tailsconfig when provisioning Journalist USB: ~/Persistent/.securedrop/torrc_additions does not exist #5997

[sssoleileraaa]

2.0.0 QA Checklist - Upgrade hardware installation
Environment
• Install target: NUC 7i5BNH
• Tails version: 4.17
• Test Scenario: upgrade from 1.8.2
• SSH over Tor: yes
• Release candidate: rc2
• General notes:
Upgrade

1. securedrop-admin backup
2. Modify /etc/apt/sources.list.d/apt_freedom_press.list and /etc/apt/security.list to point to apt-test.freedom.press, then sudo apt update && sudo apt full-upgrade on app and mon servers
3. Confirm package versions:
   • apt-cache policy securedrop-config -> Installed: 0.1.4+2.0.0~rc2+focal
   • apt-cache policy securedrop-app-code -> Installed: 2.0.0~rc2+focal
   • apt-cache policy securedrop-ossec-agent -> Installed: 3.6.0+2.0.0~rc2+focal
   • apt-cache policy securedrop-ossec-server -> Installed: 3.6.0+2.0.0~rc2+focal (mon)
4. sudo unattended-upgrades -d
   Kernel testing on app server
   ☑︎ paxtest blackhat has expected results
   • strcpy and strcpy, PIE should be paxtest: return address contains a NULL byte
   • Randomization tests: bit guesses in the high 20s or higher (there may be one or two in the mid-20s, this is still okay).
   • Everything else: "Killed"
     Note: memcpy shows Vulnerable
     ☑︎ curl -L https://meltdown.ovh -o meltdown.sh && sudo bash meltdown.sh -v- No tests come back asSTATUS:VULNERABLE`
   • Expected NUC7i5BNH false-positive on the Foreshadow L1TF test (Test failure on 4.14.154-grsec-securedrop using NUC7i7DNHE  #5040 (comment))
     Basic Server Testing
     ☑︎ I can access both the source and journalist interfaces
     ☑︎ I can SSH into both machines over Tor
     ☑︎ AppArmor is loaded on app
     ☑︎ 0 processes are running unconfined
     ☑︎ AppArmor is loaded on mon
     ☑︎ 0 processes are running unconfined
     ☑︎ Both servers are running grsec kernels
     ☑︎ iptables rules loaded
     ☑︎ OSSEC emails begin to flow after install
     ☑︎ OSSEC emails are decrypted to correct key and I am able to decrypt them
     ☑︎ 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
     Administration (skip)
     ☐ I have backed up and successfully restored the app server following the backup documentation
     ☐ If doing upgrade testing, make a backup on 1.8.2 and restore this backup on this release candidate N/A
     ☐ "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 not tested
     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 codename 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
     ☐ Updating occurs without issue (testing this for rc3)
     2.0.0 release-specific changes
     (testing this for rc3)

[sssoleileraaa]

2.0.0 QA Checklist

Environment

• Install target: NUC 7i5BNH
• Tails version: 4.17
• Test Scenario: upgrade from 1.8.2
• SSH over Tor: yes
• Release candidate: rc3
• General notes:

Downgrade

Since this is the second RC that I'm testing, I downgraded the servers back to 1.8.2 by following these steps:

1. Change /etc/apt/sources.list.d/apt_freedom_press.list and /etc/apt/security.list to point to apt.freedom.press on app and mon servers
2. apt remove securedrop-* packages and make sure apt-cache is clean
3. run securedrop-admin install on my app and mon servers. I ran into this issue: Migration error on upgrade when database is reset via manage.py #4839 but got around it by following the workaround in that issue.
4. Confirm installed package versions are back to 1.8.2 on app and mon servers
   • apt-cache policy securedrop-app-code -> Installed: 1.8.2+focal
   • apt-cache policy securedrop-config -> Installed: 0.1.4+1.8.2+focal
   • apt-cache policy securedrop-keyring -> Installed: 0.1.5+1.8.2+focal
   • apt-cache policy securedrop-ossec-agent -> Installed: 3.6.0+1.8.2+focal
   • apt-cache policy securedrop-ossec-server -> Installed: 3.6.0+1.8.2+focal (mon)

Upgrade

1. securedrop-admin backup
2. Modify /etc/apt/sources.list.d/apt_freedom_press.list and /etc/apt/security.list to point to apt-test.freedom.press
3. sudo unattended-upgrades -d and confirm package versions:
   • apt-cache policy securedrop-app-code -> Installed: 2.0.0~rc3+focal
   • apt-cache policy securedrop-config -> Installed: 0.1.4+2.0.0~rc3+focal
   • apt-cache policy securedrop-keyring -> Installed: 0.1.5+2.0.0~rc3+focal
   • apt-cache policy securedrop-ossec-agent -> Installed: 3.6.0+2.0.0~rc3+focal
   • apt-cache policy securedrop-ossec-server -> Installed: 3.6.0+2.0.0~rc3+focal (mon)

Kernel testing on app server

• paxtest blackhat has expected results
  • memcpy and memcpy, PIE shows vulnerable (see Use paxtest for validating grsecurity config #1039 (comment))
  • strcpy and strcpy, PIEshowpaxtest: return address contains a NULL byte`
  • Randomization tests: bit guesses in the high 20s or higher (there may be one or two in the mid-20s, this is still okay).
  • Everything else: "Killed"
• curl -L https://meltdown.ovh -o meltdown.sh && sudo bash meltdown.sh -v
  • CVE-2018-365 aka 'Foreshadow (SGX), L1 terminal fault' shows vulnerable (see Test failure on 4.14.154-grsec-securedrop using NUC7i7DNHE  #5040 (comment))
  • Other tests do not show vulnerable

Basic Server Testing

• I can access both the source and journalist interfaces
• I can SSH into both machines over Tor
• AppArmor is loaded on app
  • 0 processes are running unconfined
• AppArmor is loaded on mon
  • 0 processes are running unconfined
• Both servers are running grsec kernels
• iptables rules loaded
• OSSEC emails begin to flow after install
• OSSEC emails are decrypted to correct key and I am able to decrypt them

❌ ./securedrop-admin --force verify has expected results

• git checkout 2.0.0~rc3 && cd ~/Persistent/securedrop && ./securedrop-admin setup -t && ./securedrop-admin --force verify
• Tests pass except for:
  • common/test_fpf_apt_repo.py::test_fpf_apt_repo_present (app)
  • common/test_fpf_apt_repo.py::test_fpf_apt_repo_present (mon)
  • common/test_grsecurity.py::test_apt_autoremove (app)
  • mon/test_postfix.py::test_postfix_generic_maps (mon)

See notes in QA Matrix

Command Line User Generation

• Can successfully add admin user and login

Administration

• I have backed up and successfully restored the app server following the backup documentation
• If doing upgrade testing, make a backup on 1.8.2 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

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 codename 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
• Updating occurs without issue

2.0.0 release-specific changes

• Removed support for v2 service configuration #5915

  • during sdconfig, there are no prompts to choose either v2 or v3 services
  • after installation, only v3 services are referenced in /etc/tor/torrc for app and mon
  • only v3 services are defined under /var/lib/tor/services - sourcev3 and journalistv3 for app, and sshv3 for app and mon if SSH-over-tor is enabled.

• Updated Tor to 0.4.5.8 #5971

  • Tor package versions are 0.4.5.8 on both app and mon

• Removed flag-for-reply #5954

  • Create a new source via the Source Interface (SI) and submit a message. Note the codename.
  • in the Journalist Interface (JI), go to the source's individual listing page and confirm that reply functionality is available with a message displayed starting with "You can write a secure reply...". Note their journalist designation.
  • Log into the app server and find the source's filesystem_id either directly or via the command (as the www-data user:

    sqlite3 /var/lib/securedrop/db.sqlite "select filesystem_id from sources where journalist_designation = '<journalist designation>'"
    

  • Delete the source's reply keys with the commands (as www-data):

    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-secret-keys FILESYSTEM_ID
    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-keys FILESYSTEM_ID
    

  • Purge the redis cache (as root) with: redis-cli del sd/crypto-util/fingerprints
  • in the JI, reload the individual source page and confirm that replies are disabled, with a message displayed starting with "This source has no encryption keys..."
  • in the SI, log back in as the same source and submit a message
  • in the JI, reload the source's individual listing page and confirm that reply functionality is available again, with a message displayed starting with "You can write a secure reply...". Note their journalist designation.

• Removed v2 field from metadata endpoint #5926

  • Visit the http://<source interface>/metadata endpoint and confirm that the source_v2_url field is not displayed and the source_v3_url address is displayed and has the correct value.

• Store directory is recreated if missing for an existing source #5944

  • Create a source on the SI and submit one or more messages. Note the codename
  • In the JI, delete the source's files and messages while preserving the source account. Note their journalist designation
  • Log into the app server, identify the filesystem ID for the source, and delete the directory /var/lib/securedrop/store/<filesystem ID>
  • Log back into the SI as the source and submit a message, confirm that the submission completes successfully
  • Verify that the message can be downloaded via the JI

• Missing file error message text update #5905

  • Create a source in the SI and submit a message
  • Log in to the app server and delete the encrypted message file corresponding to the submission
  • Log in to the JI, go to the source's individual listing page, and attempt to download the message
  • Confirm that an error message is displayed starting with: "Your download failed because the file could not be found."

• invalid image error message text update #5932

  • Log into the app server, note existing permissions on the /var/www/securedrop/static/i directory, and change them via chmod 555 /var/www/securedrop/static/i
  • Log into the JI and attempt to upload a PNG logo image
  • Verify that the upload fails and the error message includes the word "Please."
  • return the changed directory permissions to their original value

• Logo image served as static resource #5874

  • Visit the SI and JI and verify that on both, the logo image URL path component is i/logo.png
  • On the JI, upload a custom logo, and verify that the SI and JI both display the new custom logo, with URL path component i/custom_logo.png

• /sources/<uuid>/conversation endpoint deletes source files while retaining source account #5963

  • in the JI, delete all sources.
  • in the SI, create 3 sources all with multiple files and messages
  • Download this test script to the Admin workstation, edit the script to add in the JI address and journalist account details for your instance, then follow the instructions to run it
  • Confirm that the script runs successfully
  • in the JI, confirm that the files and messages for the second source are deleted, while the other two are preserved.

• upload-screenshots.py removed from application package #5941

  • log into the application server and confirm that the file /var/www/securedrop/upload-screenshots.py is not present.

• Jounalist workstation can be configured without tor_v3_keys.json being present #5965

  • Confirm that a new journalist workstation can be provisioned using only the app-sourcev3-ths and app-journalist.auth_private files from the Admin Workstation, and that no errors about tor_v3_keys.json are obverved during the tailsconfig command on the new workstation.

[kushaldas]

I can now verify what @zenmonkeykstop also noticed via unattended-upgrade -d, securedrop-app-code was not upgraded.

<snipped>
Checking: securedrop-app-code ([<Origin component:'main' archive:'' origin:'SecureDrop' label:'' site:'apt-test.freedom.press' isTrusted:True>])              
sanity check failed for: {'haveged=1.9.1-6ubuntu1', 'securedrop-app-code=2.0.0~rc3+focal'} : pkg haveged is marked to be deleted                              
falling back to adjusting securedrop-app-code's dependencies                                                                                                  
sanity check failed for: {'haveged=1.9.1-6ubuntu1', 'securedrop-app-code=2.0.0~rc3+focal'} : pkg haveged is marked to be deleted                              
Checking: securedrop-config ([<Origin component:'main' archive:'' origin:'SecureDrop' label:'' site:'apt-test.freedom.press' isTrusted:True>])                
Checking: securedrop-keyring ([<Origin component:'main' archive:'' origin:'SecureDrop' label:'' site:'apt-test.freedom.press' isTrusted:True>])               
Checking: securedrop-ossec-agent ([<Origin component:'main' archive:'' origin:'SecureDrop' label:'' site:'apt-test.freedom.press' isTrusted:True>])           
Checking: tor ([<Origin component:'main' archive:'' origin:'SecureDrop' label:'' site:'apt-test.freedom.press' isTrusted:True>])                              
pkgs that look like they should be upgraded: securedrop-config                                                                                                
securedrop-keyring                                                                                                                                            
securedrop-ossec-agent                                                                                                                                        
tor                                                                                                                                                           
Get:1 https://apt-test.freedom.press focal/main amd64 securedrop-config all 0.1.4+2.0.0~rc3+focal [3064 B]                                                    
Get:2 https://apt-test.freedom.press focal/main amd64 securedrop-keyring amd64 0.1.5+2.0.0~rc3+focal [8120 B]                                                 
Get:3 https://apt-test.freedom.press focal/main amd64 securedrop-ossec-agent amd64 3.6.0+2.0.0~rc3+focal [4664 B]                                             
Get:4 https://apt-test.freedom.press focal/main amd64 tor amd64 0.4.5.8-1~focal+1 [1488 kB]                                                                   
Fetched 1503 kB in 0s (0 B/s)                                                                                                                                 
fetch.run() result: 0                                                                                                                                         
dpkg is configured not to cause conffile prompts                                                                                                              
Packages that will be upgraded: securedrop-config securedrop-keyring securedrop-ossec-agent tor 


<snipped>

Log started: 2021-06-21  06:57:55
(Reading database ... 46453 files and directories currently installed.)
Preparing to unpack .../tor_0.4.5.8-1~focal+1_amd64.deb ...
Unpacking tor (0.4.5.8-1~focal+1) over (0.4.5.7-1~focal+1) ...
Setting up tor (0.4.5.8-1~focal+1) ...
Processing triggers for man-db (2.9.1-1) ...
Processing triggers for systemd (245.4-4ubuntu3.7) ...
left to upgrade set()
All upgrades installed
InstCount=0 DelCount=0 BrokenCount=0
Package securedrop-app-code has a higher version available, checking if it is from an allowed origin and is not pinned down.
Package securedrop-app-code is kept back because a related package is kept back or due to local apt_preferences(5).
Extracting content from /var/log/unattended-upgrades/unattended-upgrades-dpkg.log since 2021-06-21 06:57:34

[kushaldas]

From 1.8.2 I can upgrade to SecureDrop 2.0.0~rc5 using the command sudo unattended-upgrade -d. I can also verify that the haveged is masked.

vagrant@app-prod:~$ sudo systemctl status haveged
● haveged.service
     Loaded: masked (Reason: Unit haveged.service is masked.)
     Active: inactive (dead)

Jun 23 16:16:05 app-prod systemd[1]: Started Entropy daemon using the HAVEGE algorithm.
Jun 23 16:16:05 app-prod haveged[541]: haveged starting up
Jun 23 16:16:06 app-prod haveged[541]: haveged: ver: 1.9.1; arch: x86; vend: GenuineIntel; build: (gcc 8.3.0 ITV); collect: 128K
Jun 23 16:16:06 app-prod haveged[541]: haveged: cpu: (L4 VC); data: 32K (L2 L4 V); inst: 32K (L2 L4 V); idx: 24/40; sz: 31410/52825
Jun 23 16:16:06 app-prod haveged[541]: haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B):  last entropy estimate 7.9984
Jun 23 16:16:06 app-prod haveged[541]: haveged: fills: 0, generated: 0
Jun 23 16:22:27 app-prod systemd[1]: Stopping Entropy daemon using the HAVEGE algorithm...
Jun 23 16:22:27 app-prod haveged[541]: haveged: Stopping due to signal 15
Jun 23 16:22:27 app-prod systemd[1]: haveged.service: Succeeded.
Jun 23 16:22:27 app-prod systemd[1]: Stopped Entropy daemon using the HAVEGE algorithm.

[zenmonkeykstop]

2.0.0 QA Checklist

Environment

• Install target: VMs
• Tails version: 4.19
• Test Scenario: fresh
• SSH over Tor: no
• Release candidate: rc5
• General notes:

Basic Server Testing

• I can access both the source and journalist interfaces
• I can SSH into both machines over Tor
• AppArmor is loaded on app
  • 0 processes are running unconfined
• AppArmor is loaded on mon
  • 0 processes are running unconfined
• Both servers are running grsec kernels
• iptables rules loaded
• OSSEC emails begin to flow after install not tested
• OSSEC emails are decrypted to correct key and I am able to decrypt them not tested
• 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

Administration SKIPPED

Application Acceptance Testing SKIPPED

Basic Tails Testing

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

• The Updater GUI appears on boot
• Updating occurs without issue

2.0.0 release-specific changes

• Removed support for v2 service configuration #5915

  • during sdconfig, there are no prompts to choose either v2 or v3 services
  • after installation, only v3 services are referenced in /etc/tor/torrc for app and mon
  • only v3 services are defined under /var/lib/tor/services - sourcev3 and journalistv3 for app, and sshv3 for app and mon if SSH-over-tor is enabled.

• Updated Tor to 0.4.5.8 #5971

  • Tor package versions are 0.4.5.8 on both app and mon

• Removed flag-for-reply #5954

  • Create a new source via the Source Interface (SI) and submit a message. Note the codename.
  • in the Journalist Interface (JI), go to the source's individual listing page and confirm that reply functionality is available with a message displayed starting with "You can write a secure reply...". Note their journalist designation.
  • Log into the app server and find the source's filesystem_id either directly or via the command (as the www-data user:

    sqlite3 /var/lib/securedrop/db.sqlite "select filesystem_id from sources where journalist_designation = '<journalist designation>'"
    

  • Delete the source's reply keys with the commands (as www-data):

    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-secret-keys FILESYSTEM_ID
    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-keys FILESYSTEM_ID
    

  • Purge the redis cache (as root) with: redis-cli del sd/crypto-util/fingerprints
  • in the JI, reload the individual source page and confirm that replies are disabled, with a message displayed starting with "This source has no encryption keys..."
  • in the SI, log back in as the same source and submit a message
  • in the JI, reload the source's individual listing page and confirm that reply functionality is available again, with a message displayed starting with "You can write a secure reply...". Note their journalist designation.

• Removed v2 field from metadata endpoint #5926

  • Visit the http://<source interface>/metadata endpoint and confirm that the source_v2_url field is not displayed and the source_v3_url address is displayed and has the correct value.

• Store directory is recreated if missing for an existing source #5944

  • Create a source on the SI and submit one or more messages. Note the codename
  • In the JI, delete the source's files and messages while preserving the source account. Note their journalist designation
  • Log into the app server, identify the filesystem ID for the source, and delete the directory /var/lib/securedrop/store/<filesystem ID>
  • Log back into the SI as the source and submit a message, confirm that the submission completes successfully
  • Verify that the message can be downloaded via the JI

• Missing file error message text update #5905

  • Create a source in the SI and submit a message
  • Log in to the app server and delete the encrypted message file corresponding to the submission
  • Log in to the JI, go to the source's individual listing page, and attempt to download the message
  • Confirm that an error message is displayed starting with: "Your download failed because the file could not be found."

• invalid image error message text update #5932

  • Log into the app server, note existing permissions on the /var/www/securedrop/static/i directory, and change them via chmod 555 /var/www/securedrop/static/i
  • Log into the JI and attempt to upload a PNG logo image
  • Verify that the upload fails and the error message includes the word "Please."
  • return the changed directory permissions to their original value

• Logo image served as static resource #5874

  • Visit the SI and JI and verify that on both, the logo image URL path component is i/logo.png
  • On the JI, upload a custom logo, and verify that the SI and JI both display the new custom logo, with URL path component i/custom_logo.png

• /sources/<uuid>/conversation endpoint deletes source files while retaining source account #5963 SKIPPED

  • in the JI, delete all sources.
  • in the SI, create 3 sources all with multiple files and messages
  • Download this test script to the Admin workstation, edit the script to add in the JI address and journalist account details for your instance, then follow the instructions to run it
  • Confirm that the script runs successfully
  • in the JI, confirm that the files and messages for the second source are deleted, while the other two are preserved.

• upload-screenshots.py removed from application package #5941

  • log into the application server and confirm that the file /var/www/securedrop/upload-screenshots.py is not present.

• Jounalist workstation can be configured without tor_v3_keys.json being present #5965

  • Confirm that a new journalist workstation can be provisioned using only the app-sourcev3-ths and app-journalist.auth_private files from the Admin Workstation, and that no errors about tor_v3_keys.json are obverved during the tailsconfig command on the new workstation.

Preflight testing

Basic testing

• Install or upgrade occurs without error
• Source interface is available and version string indicates it is 2.0.0
• A message can be successfully submitted

Tails

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

[rmol]

2.0.0 QA Checklist

Environment

• Install target: NUC8/NUC10
• Tails version: 4.19
• Test Scenario: upgrade
• SSH over Tor: yes
• Release candidate: rc5
• General notes:

Basic Server Testing

• I can access both the source and journalist interfaces
• I can SSH into both machines over Tor
• AppArmor is loaded on app
  • 0 processes are running unconfined
• AppArmor is loaded on mon
  • 0 processes are running unconfined
• Both servers are running grsec kernels
• iptables rules loaded
• OSSEC emails begin to flow after install
• OSSEC emails are decrypted to correct key and I am able to decrypt them
• 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

Administration: SKIPPED

Application Acceptance Testing: SKIPPED

Basic Tails Testing: SKIPPED

2.0.0 release-specific changes

• Removed support for v2 service configuration #5915

  • during sdconfig, there are no prompts to choose either v2 or v3 services
  • after installation, only v3 services are referenced in /etc/tor/torrc for app and mon
  • only v3 services are defined under /var/lib/tor/services - sourcev3 and journalistv3 for app, and sshv3 for app and mon if SSH-over-tor is enabled.

• Updated Tor to 0.4.5.8 #5971

  • Tor package versions are 0.4.5.8 on both app and mon

• Removed flag-for-reply #5954, #6008, #6011

  • Create a new source via the Source Interface (SI). Note the codename so you can log in later as this source.
  • On the app server, run gpg --homedir /var/lib/securedrop/keys --list-keys and confirm that you see one key for the new source.
  • Submit a message.
  • List the GPG keys again and confirm that the source still has the same single key.
  • in the Journalist Interface (JI), go to the source's individual listing page and confirm that reply functionality is available with a message displayed starting with "You can write a secure reply...". Note their journalist designation.
  • Log into the app server and find the source's filesystem_id either directly or via the command (as the www-data user:

    sqlite3 /var/lib/securedrop/db.sqlite "select filesystem_id from sources where journalist_designation = '<journalist designation>'"
    

  • Delete the source's reply keys with the commands (as www-data):

    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-secret-keys FILESYSTEM_ID
    gpg --homedir /var/lib/securedrop/keys --yes --pinentry-mode=loopback --delete-keys FILESYSTEM_ID
    

  • Purge the redis cache (as root) with: redis-cli del sd/crypto-util/fingerprints
  • in the JI, reload the individual source page and confirm that replies are disabled, with a message displayed starting with "This source has no encryption keys..."
  • in the SI, log back in as the same source and submit a message
  • in the JI, reload the source's individual listing page and confirm that reply functionality is available again, with a message displayed starting with "You can write a secure reply...". Note their journalist designation.
  • if this is an upgrade from 1.8.2, ssh app sudo systemctl status haveged shows that haveged is stopped, disabled, and masked
  • if this is a fresh install, ssh app apt-cache policy haveged shows that haveged is not installed.

• Removed v2 field from metadata endpoint #5926

  • Visit the http://<source interface>/metadata endpoint and confirm that the source_v2_url field is not displayed and the source_v3_url address is displayed and has the correct value.

• Store directory is recreated if missing for an existing source #5944

  • Create a source on the SI and submit one or more messages. Note the codename
  • In the JI, delete the source's files and messages while preserving the source account. Note their journalist designation
  • Log into the app server, identify the filesystem ID for the source, and delete the directory /var/lib/securedrop/store/<filesystem ID>
  • Log back into the SI as the source and submit a message, confirm that the submission completes successfully
  • Verify that the message can be downloaded via the JI

• Missing file error message text update #5905

  • Create a source in the SI and submit a message
  • Log in to the app server and delete the encrypted message file corresponding to the submission
  • Log in to the JI, go to the source's individual listing page, and attempt to download the message
  • Confirm that an error message is displayed starting with: "Your download failed because the file could not be found."

• invalid image error message text update #5932

  • Log into the app server, note existing permissions on the /var/www/securedrop/static/i directory, and change them via chmod 555 /var/www/securedrop/static/i
  • Log into the JI and attempt to upload a PNG logo image
  • Verify that the upload fails and the error message includes the word "Please."
  • return the changed directory permissions to their original value

• Logo image served as static resource #5874

  • Visit the SI and JI and verify that on both, the logo image URL path component is i/logo.png
  • On the JI, upload a custom logo, and verify that the SI and JI both display the new custom logo, with URL path component i/custom_logo.png

• /sources/<uuid>/conversation endpoint deletes source files while retaining source account #5963

  • in the JI, delete all sources.
  • in the SI, create 3 sources all with multiple files and messages
  • Download this test script to the Admin workstation, edit the script to add in the JI address and journalist account details for your instance, then follow the instructions to run it
  • Confirm that the script runs successfully
  • in the JI, confirm that the files and messages for the second source are deleted, while the other two are preserved.

• upload-screenshots.py removed from application package #5941

  • log into the application server and confirm that the file /var/www/securedrop/upload-screenshots.py is not present.

• Jounalist workstation can be configured without tor_v3_keys.json being present #5965

  • Confirm that a new journalist workstation can be provisioned using only the app-sourcev3-ths and app-journalist.auth_private files from the Admin Workstation, and that no errors about tor_v3_keys.json are obverved during the tailsconfig command on the new workstation.