Release SecureDrop 1.4.0

[conorsch]

This is a tracking issue for the release of SecureDrop 1.4.0

String and feature freeze: N/A (no string changes)
String comment period: N/A (no string changes)
Translation period: N/A (no string changes)
Pre-release announcement: 2020-06-10
Translation freeze: N/A (no string changes)
Release date: 2020-06-17

Release manager: @conorsch
Deputy release manager: @creviera
Localization manager: N/A
Deputy localization manager: N/A

SecureDrop maintainers and testers: As you QA 1.4.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 1.4.0 milestone for tracking (or ask a maintainer to do so). The test plan TK

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 1.4.0

Test Plan for 1.4.0

Prepare release candidate (1.4.0~rc1)

• Prepare 1.4.0~rc1 release changelog
• Branch off release/1.4.0 from develop
• Prepare 1.4.0~rc1
• Build debs and put up 1.4.0~rc1 on test apt server (this is now done via a PR into this repository) - SecureDrop core packages for 1.4.0-rc1 securedrop-apt-test#44
• Commit build logs to https://github.com/freedomofpress/build-logs

After each test, please update the QA matrix and post details for Basic Server Testing, Application Acceptance Testing and 1.4.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
• Build final Debian packages for 1.4.0 (and preserve build logs)
• Commit package build logs to https://github.com/freedomofpress/build-logs
• Upload Debian packages to apt QA server (including new tor packages)
• Pre-Flight: Test install and upgrade (both cron-apt on Xenial, and Ansible on Xenial) of 1.4.0 works w/ prod repo debs, test updater logic in Tails
• Flip apt QA server to prod status
• merge the release branch changes to master and verify new docs build
• Prepare and distribute release messaging
• Update release key on keyservers
• Update release key on securedrop.org

Post release

• Create GitHub release object
• Merge changelog back to develop
• Update upgrade testing boxes
• Update roadmap wiki page

[sssoleileraaa]

We'll need to correct the 1.4.0 changelog by replaceing #2527 with #5257

[sssoleileraaa]

https://github.com/freedomofpress/securedrop/wiki/1.4.0-Test-Plan is now live. Next, we need to update the hagrid keyserver and securedrop.org webiste with the new release signing key.

[sssoleileraaa]

https://docs.google.com/spreadsheets/d/15qr2XMlBrlCwgaErGzW9HR4UXJsRtwadwkhOPpEJmec/edit#gid=0 is ready (hardware columns we can skip during QA are marked [SKIP]) and release-specific rows are at the bottom of the matrix

[kushaldas]

1.4.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. Feel free to edit this message to update the plan as appropriate.

If you have submitted a QA report already for a 1.4.0 release candidate with successful [[Basic Server Testing]] and [[Application Acceptance Testing]], 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 1.4.0-specific changes as well as changes since the previous release candidate.

Environment

• Install target: prod vm
• Tails version: 4.7
• Test Scenario: update
• SSH over Tor: no
• Onion service version: 2 and 3
• Release candidate: rc1
• 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
• 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.3.0 and restore this backup on 1.4.0
• "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 And Submissions" and the source and docs are deleted
• You can click on a document and successfully decrypt using application private key

Basic Tails Testing

Updater GUI

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

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

1.4.0: Release-specific changes

Version updates

#5292

• Verify that Tor 0.4.3.5 is running by running sudo apt-cache policy tor

#5277

• Verify that the new securedrop-keyring package has an updated expiration date of 2021-06-30 by running sudo apt-key finger

#5287

• Verify that the 1.4.0 securedrop-ossec-agent and securedrop-ossec-server packages are being used running sudo apt-cache policy securedrop-ossec-agent and sudo apt-cache policy securedrop-ossec-server.

Web Application

#5257

• Verify the source_deleter service is running on the app server
  • Use qa_loader.py or create-dev-data.py to populate the staging database with a large number of sources (100 should be sufficient to have triggered the timeout before this change, but 500 or 1000 would be better).
  • While the database is being populated, run systemctl status securedrop_source_deleter
• Verify that the JI delete action responds quickly (no longer times out) and sources are no longer available.
  • Once the database is populated, visit the journalist interface and select all but a few of the sources for deletion.
• Verify that source_deleter deletes all sources (Deleting 1000 sources took around a half an hour during PR testing)
  • Monitor the source_deleter logs on the app server with journalctl -fu securedrop_source_deleter
• Verify that sources not deleted are still present once deletion is complete

Admin Workstation

#5287

• Verify that you receive an OSSEC alert level 12 email that says “The iptables default drop rules are incorrect.” when iptables is broken.
  • [Upgrade scenario] Run sdconfig on 1.3.0 with a broken config and run make install (to repro known-bad state), then upgrade via apt-test.
  • Break the /etc/networking/iptables/rules_ipv4 file on the servers after installation (by substituting invalid values into fields, for example), then reboot the servers.

#5288

• Verify that there are no errors in the sdconfig logic when multiple nameservers are provided during sdconfig
  • On an admin workstation, run securedrop-admin sdconfig. Try giving a single nameserver, then a list separated by commas, then by spaces. Enter invalid IP addresses. Try to enter more than three nameservers.
• Verify that the dns_server value in install_files/ansible-base/group_vars/all/site-specific is a list, not a string after specifying multiple nameservers.
• Verify that securedrop-admin install completes successfully and that each server's /etc/resolvconf/resolv.conf.d/base contains the correct nameservers.
• Verify that the dns rules contain the nameservers you provided by running Run sudo iptables -S | grep
• Verify that the value is correctly transformed to a list and that the server's /etc/resolvconf/resolv.conf.d/base and iptables rules are correct
  • Edit install_files/ansible-base/group_vars/all/site-specific to make dns_server a string, covering at least some of the variations you tested above: single, comma-separated, space-separated. Upon each change, run securedrop-admin install.

#5277

• Since we can't rely on the updater to get the new key until the release object is published (see https://github.com/zenmonkeykstop/securedrop/blob/ee9b16e39908b1bac9d9aba202eb9a50193a0923/admin/securedrop_admin/__init__.py#L665-L667), we will need to create temporary keyrings for each check.

  • Verify the SecureDrop Release signing key is present with the new expiration date of 2021-06-30 on the keyserver

    • mkdir -m 700 /tmp/qa-new-key-on-keyserver
    • gpg --homedir /tmp/qa-new-key-on-keyserver --keyserver hkps://keys.openpgp.org --recv-keys 22245C81E3BAEB4138B36061310F561200F4AD77
    • gpg --homedir /tmp/qa-new-key-on-keyserver -k

  • Verify the SecureDrop Release signing key is present with the new expiration date of 2021-06-30 on securedrop.org

    • mkdir -m 700 /tmp/qa-new-key-on-website
    • curl -LO https://securedrop.org/securedrop-release-key.asc
    • gpg --homedir /tmp/qa-new-key-on-website --import securedrop-release-key.asc
    • gpg --homedir /tmp/qa-new-key-on-website -k

Preflight

• Ensure the builder image is up-to-date on release day

These tests should be performed the day of release prior to live debian packages on apt.freedom.press.

Basic testing

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

Tails

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

[rmol]

Environment

• Install target: NUC 7i5BNH
• Tails version: 4.7
• Test Scenario: clean install
• SSH over Tor: yes
• Onion service version: 3
• Release candidate: 1.4.0rc1
• 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
• 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.3.0 and restore this backup on 1.4.0
• "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 And Submissions" and the source and docs are deleted
• You can click on a document and successfully decrypt using application private key

Basic Tails Testing

Updater GUI

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

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

1.4.0: Release-specific changes

Version updates

#5292

• Verify that Tor 0.4.3.5 is running by running sudo apt-cache policy tor

#5277

• Verify that the new securedrop-keyring package has an updated expiration date of 2021-06-30 by running sudo apt-key finger

#5287

• Verify that the 1.4.0 securedrop-ossec-agent and securedrop-ossec-server packages are being used running sudo apt-cache policy securedrop-ossec-agent and sudo apt-cache policy securedrop-ossec-server.

Web Application

#5257

• Verify the source_deleter service is running on the app server
  • Use qa_loader.py or create-dev-data.py to populate the staging database with a large number of sources (100 should be sufficient to have triggered the timeout before this change, but 500 or 1000 would be better).
  • While the database is being populated, run systemctl status securedrop_source_deleter
• Verify that the JI delete action responds quickly (no longer times out) and sources are no longer available.
  • Once the database is populated, visit the journalist interface and select all but a few of the sources for deletion.
• Verify that source_deleter deletes all sources (Deleting 1000 sources took around a half an hour during PR testing)
  • Monitor the source_deleter logs on the app server with journalctl -fu securedrop_source_deleter
• Verify that sources not deleted are still present once deletion is complete

Admin Workstation

#5287

• Verify that you receive an OSSEC alert level 12 email that says “The iptables default drop rules are incorrect.” when iptables is broken.
  • [Upgrade scenario] Run sdconfig on 1.3.0 with a broken config and run make install (to repro known-bad state), then upgrade via apt-test.
  • Break the /etc/networking/iptables/rules_ipv4 file on the servers after installation (by substituting invalid values into fields, for example), then reboot the servers.

#5288

• Verify that there are no errors in the sdconfig logic when multiple nameservers are provided during sdconfig
  • On an admin workstation, run securedrop-admin sdconfig. Try giving a single nameserver, then a list separated by commas, then by spaces. Enter invalid IP addresses. Try to enter more than three nameservers.
• Verify that the dns_server value in install_files/ansible-base/group_vars/all/site-specific is a list, not a string after specifying multiple nameservers.
• Verify that securedrop-admin install completes successfully and that each server's /etc/resolvconf/resolv.conf.d/base contains the correct nameservers.
• Verify that the dns rules contain the nameservers you provided by running Run sudo iptables -S | grep
• Verify that the value is correctly transformed to a list and that the server's /etc/resolvconf/resolv.conf.d/base and iptables rules are correct
  • Edit install_files/ansible-base/group_vars/all/site-specific to make dns_server a string, covering at least some of the variations you tested above: single, comma-separated, space-separated. Upon each change, run securedrop-admin install.

#5277

• Since we can't rely on the updater to get the new key until the release object is published (see https://github.com/zenmonkeykstop/securedrop/blob/ee9b16e39908b1bac9d9aba202eb9a50193a0923/admin/securedrop_admin/__init__.py#L665-L667), we will need to create temporary keyrings for each check.

  • Verify the SecureDrop Release signing key is present with the new expiration date of 2021-06-30 on the keyserver

    • mkdir -m 700 /tmp/qa-new-key-on-keyserver
    • gpg --homedir /tmp/qa-new-key-on-keyserver --keyserver hkps://keys.openpgp.org --recv-keys 22245C81E3BAEB4138B36061310F561200F4AD77
    • gpg --homedir /tmp/qa-new-key-on-keyserver -k

  • Verify the SecureDrop Release signing key is present with the new expiration date of 2021-06-30 on securedrop.org

    • mkdir -m 700 /tmp/qa-new-key-on-website
    • curl -LO https://securedrop.org/securedrop-release-key.asc
    • gpg --homedir /tmp/qa-new-key-on-website --import securedrop-release-key.asc
    • gpg --homedir /tmp/qa-new-key-on-website -k

[zenmonkeykstop]

QA plan

There is no kernel update in this release, so we’ll be testing on fewer hardware platforms. However, given the importance of the iptables check, we’ll test the officially supported hardware:

• NUC7
• 1U test server

1.4.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. Feel free to edit this message to update the plan as appropriate.

If you have submitted a QA report already for a 1.4.0 release candidate with successful [[Basic Server Testing]] and [[Application Acceptance Testing]], 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 1.4.0-specific changes as well as changes since the previous release candidate.

Environment

• Install target: 1U servers
• Tails version: 4.7
• Test Scenario: cron-apt update
• SSH over Tor: yes
• Onion service version: v3
• Release candidate: 1.4.0-rc1
• 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 FAIL, as set up with 1.3.0 broken dns field
• OSSEC emails begin to flow after install
• OSSEC emails are decrypted to correct key and I am able to decrypt them
• 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.3.0 and restore this backup on 1.4.0 SKIPPED. no backup available
• "Send Test OSSEC Alert" button in the journalist triggers an OSSEC alert and an email is sent FAIL - alert not sent, nothing in logs
• 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 not 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 And Submissions" and the source and docs are deleted
• You can click on a document and successfully decrypt using application private key

Basic Tails Testing

Updater GUI

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

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

1.4.0: Release-specific changes

Version updates

#5292

• Verify that Tor 0.4.3.5 is running by running sudo apt-cache policy tor

#5277

• Verify that the new securedrop-keyring package has an updated expiration date of June 30, 2021 by running sudo apt-key finger

#5287

• Verify that the 1.4.0 securedrop-ossec-agent and securedrop-ossec-server packages are being used running sudo apt-cache policy securedrop-ossec-agent and sudo apt-cache policy securedrop-ossec-server.

Web Application

#5257

• Verify the source_deleter service is running on the app server
  • Use qa_loader.py or create-dev-data.py to populate the staging database with a large number of sources (100 should be sufficient to have triggered the timeout before this change, but 500 or 1000 would be better).
  • While the database is being populated, run systemctl status securedrop_source_deleter
• Verify that the JI delete action responds quickly (no longer times out) and sources are no longer available.
  • Once the database is populated, visit the journalist interface and select all but a few of the sources for deletion.
• Verify that source_deleter deletes all sources (Deleting 1000 sources took around a half an hour during PR testing)
  • Monitor the source_deleter logs on the app server with journalctl -fu securedrop_source_deleter
• Verify that sources not deleted are still present once deletion is complete

Admin Workstation

#5287

• Verify that you receive an OSSEC alert level 12 email that says “The iptables default drop rules are incorrect.” when iptables is broken.
  • [Upgrade scenario] Run sdconfig on 1.3.0 with a broken config and run make install (to repro known-bad state), then upgrade via apt-test.
  • Break the /etc/networking/iptables/rules_ipv4 file on the servers after installation (by substituting invalid values into fields, for example), then reboot the servers.

#5288

• Verify that there are no errors in the sdconfig logic when multiple nameservers are provided during sdconfig
  • On an admin workstation, run securedrop-admin sdconfig. Try giving a single nameserver, then a list separated by commas, then by spaces. Enter invalid IP addresses. Try to enter more than three nameservers.
• Verify that the dns_server value in install_files/ansible-base/group_vars/all/site-specific is a list, not a string after specifying multiple nameservers.
• Verify that securedrop-admin install completes successfully and that each server's /etc/resolvconf/resolv.conf.d/base contains the correct nameservers. tested with single entry: pass. tested with double entry: pass
• Verify that the dns rules contain the nameservers you provided by running Run sudo iptables -S | grep
• Verify that the value is correctly transformed to a list and that the server's /etc/resolvconf/resolv.conf.d/base and iptables rules are correct
  • Edit install_files/ansible-base/group_vars/all/site-specific to make dns_server a string, covering at least some of the variations you tested above: single, comma-separated, space-separated. Upon each change, run securedrop-admin install.

#5277

• Verify the SecureDrop Release signing key is present with the new expiration date of June 30, 2021 in the local keyring.
  • After install, run gpg -k [email protected].

Preflight

• Ensure the builder image is up-to-date on release day

These tests should be performed the day of release prior to live debian packages on apt.freedom.press.

Basic testing

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

Tails

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

[conorsch]

"Send Test OSSEC Alert" button in the journalist triggers an OSSEC alert and an email is sent FAIL - alert not sent, nothing in logs

Sounds like #5265. Failure may be logged under procmail.

Verify that you receive an OSSEC alert level 12 email that says “The iptables default drop rules are incorrect.” when iptables is broken. FAIL: got OSSEC alert after initial (natural) cron-apt, but no alerts of any kind after running playbook to correct DNS server entries

I do see such an email alert from 2020-06-11, but that's likely too old for the current test report you're filing. What about in /var/ossec/logs/alerts/alerts.log, do you see a level 12 alert there?

[eloquence]

Sounds like #5265.

That was my original experience after upgrading to 1.3.0, before rebooting. After rebooting, the test alerts did send (while permission errors continued to be logged), with the email body documented here:

#5265 (comment)

[conorsch]

All PRs have been backported, proceeding with final tag for 1.4.0.

[zenmonkeykstop]

(For historical purposes, the OSSEC agent failure mentioned above was tracked down to a misconfiguration in QA firewall rules, not a code issue)

[eloquence]

Fully closed out by #5329.