Release SecureDrop 0.12.0

[heartsucker]

This is a tracking issue for the upcoming release of SecureDrop 0.12.0 - tasks may get added or modified.

Feature freeze: EOD Pacific time, Tuesday, Feb 12
String freeze: Tuesday, Feb 19
Pre-release announcement: Tuesday, Feb 19
Release date: Tuesday, Feb 26

Release manager: @heartsucker
Deputy release manager: @emkll

SecureDrop maintainers and testers: As you QA 0.12.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 0.12.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.

Prepare release candidate (0.12.0~rc1)

• Prepare 0.12.0-rc1 release changelog - @heartsucker
• Branch off 0.12.0~rc1 into release/0.12.0 - @heartsucker
• Build debs (including new Tor package) and put up 0.12.0~rc1 on test apt server - @emkll

QA Matrix for 0.12.0

Test Plan for 0.12.0

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

Prepare next release candidate (0.12.0~rc2)

• Prepare 0.12.0-rc2 release candidate - @heartsucker
• Build debs and put up 0.12.0~rc2 on test apt server - @emkll

Final release

• Ensure builder in release branch is updated and/or update builder image - @emkll
• Merge final translations -
• Push signed tag -
• Build final Debian packages for 0.12.0 (including kernels and Tor packages)- @conorsch
• Upload Debian packages to apt test - @conorsch
• Pre-Flight: Test install and upgrade (both cron-apt on Trusty, and Ansible on Xenial) of 0.12.0 works w/ prod repo debs, test updater logic in Tails, ensure tor --version returns 0.3.4.9 -
• Prepare and distribute pre-release messaging - @eloquence - [0.12.0] Write and disseminate pre-release announcement #4154
• Prepare and distribute release messaging - @eloquence - [0.12.0] Write and disseminate release announcement #4181

Post release

• Merge changelog (i.e. rc commits and
  9120b37) back to develop - @heartsucker - Backport changelog #4210
• Bump version on develop in prep for 0.13.0 release - @heartsucker - Backport changelog #4210
• Update upgrade testing boxes - @conorsch
• Update roadmap wiki page - @eloquence

[emkll]

Clean install - 0.12.0-rc2

Environment

• Install target: Prod VMs
• Tails version: 3.12.1
• Test Scenario: Clean install
• SSH over Tor: No
• 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 over local network
• 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 (4.4.167-grsec)
• 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 (TBD)

Command Line User Generation

• Can successfully add admin user and login

Administration

• I have backed up and successfully restored the app server following the documentation here: https://docs.securedrop.org/en/latest/backup_and_restore.html
• If doing upgrade testing, make a backup on 0.11.1 and restore this backup on 0.12.0

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

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

0.12.0-specific changes

• The operating system warning implemented in #4055 appears on Trusty if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• Keys generated for new sources no longer leak expiration dates, and will have a creation date of May 14, 2013. Verify this by inspecting the keyring on the application server after creation of a new source. (See #3994 for background.)
• After enabling logging in the Apache config on the sources interfaces, a single submit-download-reply flow from source to journalist and back produces no errors in /var/log/apache2/*
• There are no AppArmor denials in /var/log/kern.log (and no new warnings)
• There are no new and unexpected logs in /var/ossec/logs/ossec.log and /var/ossec/logs/alerts/alerts.log
• On a Trusty system that used cron-apt to install the latest packages, the OSSEC alerts point to securedrop.org documentation and do not say to use do-release-upgrade
• Tor version installed on app and mon is 0.3.4.9

Lower priority:

• API responses should no longer include the Set-Cookie and Vary: Cookie headers as described in #3876 and implemented in #3941
• An API consumer should be able to set a reply UUID as described in #3957 and implemented in #3958
• Creating a reply through the API should result in a response including the reply's filename as described in #4057 and implemented in #4052
• Creating an auth token through the API should result in a response including the journalist's UUID as described in #4081 and implemented in #4088
• Immediately fetching a source's public key after it was created should not return all source public keys, as described in #4005 and resolved in #4009 (note that this needs to be immediate, as in < 2 seconds)

[zenmonkeykstop]

QA plan

• NUCs
• Mac Minis
• 1U servers in SF

0.12.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 0.12.0 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 0.12.0-specific changes as well as changes since the previous release candidate.

Environment

• Install target: NUC5s
• Tails version: 3.12.1
• Test Scenario: fresh install
• SSH over Tor: yes
• Release candidate: 0.12.0-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
• 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 documentation here: https://docs.securedrop.org/en/latest/backup_and_restore.html
• If doing upgrade testing, make a backup on 0.11.1 and restore this backup on 0.12.0

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

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 - Update fails due to keyserver timeout

0.12.0-specific changes

• The operating system warning implemented in #4055 appears on Trusty if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• The operating system warning does not appear on Xenial if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• Keys generated for new sources no longer leak expiration dates, and will have a creation date of May 14, 2013. Verify this by inspecting the keyring on the application server after creation of a new source. (See #3994 for background.) (inspect the keyring as the www-data user, as doing it as root changes ownershop on pubring.gpg and breaks submissions).
• After enabling logging in the Apache config on the sources interfaces, a single submit-download-reply flow from source to journalist and back produces no errors in /var/log/apache2/*
• There are no AppArmor denials in /var/log/kern.log (and no new warnings)
• There are no new and unexpected logs in /var/ossec/logs/ossec.log and /var/ossec/logs/alerts/alerts.log This isn't well-defined IMO
• On a Trusty system that used cron-apt to install the latest packages, the OSSEC alerts point to securedrop.org documentation and do not say to use do-release-upgrade
• Tor version installed on app and mon is correct: 0.3.4.9 on Trusty, or 0.3.57 on Xenial
• Kernel version is 4.4.167-grsec on app and mon

Lower priority (TBD Feb 20 morning):

• API responses should no longer include the Set-Cookie and Vary: Cookie headers as described in #3876 and implemented in #3941
• An API consumer should be able to set a reply UUID as described in #3957 and implemented in #3958
• Creating a reply through the API should result in a response including the reply's filename as described in #4057 and implemented in #4052
• Creating an auth token through the API should result in a response including the journalist's UUID as described in #4081 and implemented in #4088
• Immediately fetching a source's public key after it was created should not return all source public keys, as described in #4005 and resolved in #4009 (note that this needs to be immediate, as in < 2 seconds)

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 0.12.0
• A message can be successfully submitted

Tails

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

[zenmonkeykstop]

Note changes to test plan:
ADDED:
* The operating system warning does not appear on Xenial if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
CHANGED:
* Tor version installed on app and mon is correct: 0.3.4.9 on Trusty, or 0.3.57 on Xenial

[emkll]

Upgrade 0.11.1 -> 0.12.0-rc2, Trusty

Environment

• Install target: Prod VMs
• Tails version: 3.12.1
• Test Scenario: Clean install
• SSH over Tor: No
• 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 over local network
• 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 (4.4.167-grsec)
• 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 (TBD)

Command Line User Generation

• Can successfully add admin user and login

Administration

• I have backed up and successfully restored the app server following the documentation here: https://docs.securedrop.org/en/latest/backup_and_restore.html
• If doing upgrade testing, make a backup on 0.11.1 and restore this backup on 0.12.0

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

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

0.12.0-specific changes

• The operating system warning implemented in #4055 appears on Trusty if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• Keys generated for new sources no longer leak expiration dates, and will have a creation date of May 14, 2013. Verify this by inspecting the keyring on the application server after creation of a new source. (See #3994 for background.)
• After enabling logging in the Apache config on the sources interfaces, a single submit-download-reply flow from source to journalist and back produces no errors in /var/log/apache2/*
• There are no AppArmor denials in /var/log/kern.log (and no new warnings)
• There are no new and unexpected logs in /var/ossec/logs/ossec.log and /var/ossec/logs/alerts/alerts.log
• On a Trusty system that used cron-apt to install the latest packages, the OSSEC alerts point to securedrop.org documentation and do not say to use do-release-upgrade
• Tor version installed on app and mon is 0.3.4.9

Lower priority:

• API responses should no longer include the Set-Cookie and Vary: Cookie headers as described in #3876 and implemented in #3941
• An API consumer should be able to set a reply UUID as described in #3957 and implemented in #3958
• Creating a reply through the API should result in a response including the reply's filename as described in #4057 and implemented in #4052
• Creating an auth token through the API should result in a response including the journalist's UUID as described in #4081 and implemented in #4088
• Immediately fetching a source's public key after it was created should not return all source public keys, as described in #4005 and resolved in #4009 (note that this needs to be immediate, as in < 2 seconds)

[kushaldas]

QA plan

0.12.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 0.12.0 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 0.12.0-specific changes as well as changes since the previous release candidate.

Environment

• Install target: vm
• Tails version: 3.12.1
• Test Scenario: fresh install
• SSH over Tor: no
• Release candidate: 0.12.0-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
• 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 documentation here: https://docs.securedrop.org/en/latest/backup_and_restore.html
• If doing upgrade testing, make a backup on 0.11.1 and restore this backup on 0.12.0 (NOT DONE YET)

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

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 -

0.12.0-specific changes

• The operating system warning implemented in #4055 appears on Trusty if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• The operating system warning does not appear on Xenial if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• Keys generated for new sources no longer leak expiration dates, and will have a creation date of May 14, 2013. Verify this by inspecting the keyring on the application server after creation of a new source. (See #3994 for background.) (inspect the keyring as the www-data user, as doing it as root changes ownershop on pubring.gpg and breaks submissions).
• After enabling logging in the Apache config on the sources interfaces, a single submit-download-reply flow from source to journalist and back produces no errors in /var/log/apache2/*
• There are no AppArmor denials in /var/log/kern.log (and no new warnings)
• There are no new and unexpected logs in /var/ossec/logs/ossec.log and /var/ossec/logs/alerts/alerts.log Did not test
• On a Trusty system that used cron-apt to install the latest packages, the OSSEC alerts point to securedrop.org documentation and do not say to use do-release-upgrade
• Tor version installed on app and mon is correct: 0.3.4.9 on Trusty, or 0.3.57 on Xenial
• Kernel version is 4.4.167-grsec on app and mon

[zenmonkeykstop]

0.12.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 0.12.0 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 0.12.0-specific changes as well as changes since the previous release candidate.

Environment

• Install target: 5-series NUCS
• Tails version: 3.12.1
• Test Scenario: 0.11.1 backup/install/restore
• SSH over Tor: yes
• Release candidate: 0.12.0-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
• 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 documentation here: https://docs.securedrop.org/en/latest/backup_and_restore.html
• If doing upgrade testing, make a backup on 0.11.1 and restore this backup on 0.12.0

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

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 - Fails with keyserver timeout

0.12.0-specific changes

• The operating system warning implemented in #4055 appears on Trusty if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• The operating system warning does not appear on Xenial if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• Keys generated for new sources no longer leak expiration dates, and will have a creation date of May 14, 2013. Verify this by inspecting the keyring on the application server after creation of a new source. (See #3994 for background.)
• After enabling logging in the Apache config on the sources interfaces, a single submit-download-reply flow from source to journalist and back produces no errors in /var/log/apache2/*
• There are no AppArmor denials in /var/log/kern.log (and no new warnings)
• There are no new and unexpected logs in /var/ossec/logs/ossec.log and /var/ossec/logs/alerts/alerts.log
• On a Trusty system that used cron-apt to install the latest packages, the OSSEC alerts point to securedrop.org documentation and do not say to use do-release-upgrade
• Tor version installed on app and mon is 0.3.5.7 (Xenial) or 0.3.4.9 (Trusty)

Lower priority:

• API responses should no longer include the Set-Cookie and Vary: Cookie headers as described in #3876 and implemented in #3941
• An API consumer should be able to set a reply UUID as described in #3957 and implemented in #3958
• Creating a reply through the API should result in a response including the reply's filename as described in #4057 and implemented in #4052
• Creating an auth token through the API should result in a response including the journalist's UUID as described in #4081 and implemented in #4088
• Immediately fetching a source's public key after it was created should not return all source public keys, as described in #4005 and resolved in #4009 (note that this needs to be immediate, as in < 2 seconds)

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 0.12.0
• A message can be successfully submitted

Tails

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

[zenmonkeykstop]

QA plan

• NUCs
• Mac Minis
• 1U servers in SF

0.12.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 0.12.0 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 0.12.0-specific changes as well as changes since the previous release candidate.

Environment

• Install target: Mac Mini 2014
• Tails version: 3.12.1
• Test Scenario: upgrade-in-place, 0.12.0 Trusty to 0.12.0 Xenial
• SSH over Tor: yes
• Release candidate: 0.12.0-rc3
• 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 documentation here: https://docs.securedrop.org/en/latest/backup_and_restore.html
• If doing upgrade testing, make a backup on 0.11.1 and restore this backup on 0.12.0

Application Acceptance Testing - SKIPPED (Tested in previous RCs)

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

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 FAILS due to keyserver timeout

0.12.0-specific changes

• The operating system warning implemented in #4055 appears on Trusty if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• The operating system warning does not appear on Xenial if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• Keys generated for new sources no longer leak expiration dates, and will have a creation date of May 14, 2013. Verify this by inspecting the keyring on the application server after creation of a new source. (See #3994 for background.)
• After enabling logging in the Apache config on the sources interfaces, a single submit-download-reply flow from source to journalist and back produces no errors in /var/log/apache2/*
• There are no AppArmor denials in /var/log/kern.log (and no new warnings)
• There are no new and unexpected logs in /var/ossec/logs/ossec.log and /var/ossec/logs/alerts/alerts.log
• On a Trusty system that used cron-apt to install the latest packages, the OSSEC alerts point to securedrop.org documentation and do not say to use do-release-upgrade untested because Xenial
• Tor version installed on app and mon is 0.3.5.7
• NoScript instructions appear on the Source Interface

Lower priority:

• API responses should no longer include the Set-Cookie and Vary: Cookie headers as described in #3876 and implemented in #3941
• An API consumer should be able to set a reply UUID as described in #3957 and implemented in #3958
• Creating a reply through the API should result in a response including the reply's filename as described in #4057 and implemented in #4052
• Creating an auth token through the API should result in a response including the journalist's UUID as described in #4081 and implemented in #4088
• Immediately fetching a source's public key after it was created should not return all source public keys, as described in #4005 and resolved in #4009 (note that this needs to be immediate, as in < 2 seconds) untested, difficult to repro in prod

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 0.12.0
• A message can be successfully submitted

Tails

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

[zenmonkeykstop]

0.12.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 0.12.0 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 0.12.0-specific changes as well as changes since the previous release candidate.

Environment

• Install target: 2014 Mac Mini
• Tails version: 3.12.1
• Test Scenario: cron-apt update from 0.11.1 Trusty to 0.12.0 Trusty
• SSH over Tor: yes
• Release candidate: 0.12.0-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
• 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 documentation here: https://docs.securedrop.org/en/latest/backup_and_restore.html
• If doing upgrade testing, make a backup on 0.11.1 and restore this backup on 0.12.0

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

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 fails due to keyserver

0.12.0-specific changes

• The operating system warning implemented in #4055 appears on Trusty if XENIAL_WARNING_DATE in the journalist app is set to the current date on the app server.
• Keys generated for new sources no longer leak expiration dates, and will have a creation date of May 14, 2013. Verify this by inspecting the keyring on the application server after creation of a new source. (See #3994 for background.)
• After enabling logging in the Apache config on the sources interfaces, a single submit-download-reply flow from source to journalist and back produces no errors in /var/log/apache2/* errors related to permissions issues
• There are no AppArmor denials in /var/log/kern.log (and no new warnings) - failures related to /etc/lsb-release and the skull png
• There are no new and unexpected logs in /var/ossec/logs/ossec.log and /var/ossec/logs/alerts/alerts.log untested
• On a Trusty system that used cron-apt to install the latest packages, the OSSEC alerts point to securedrop.org documentation and do not say to use do-release-upgrade didn't receive message
• Tor version installed on app and mon is 0.3.5.7

Lower priority:

• API responses should no longer include the Set-Cookie and Vary: Cookie headers as described in #3876 and implemented in #3941
• An API consumer should be able to set a reply UUID as described in #3957 and implemented in #3958
• Creating a reply through the API should result in a response including the reply's filename as described in #4057 and implemented in #4052
• Creating an auth token through the API should result in a response including the journalist's UUID as described in #4081 and implemented in #4088
• Immediately fetching a source's public key after it was created should not return all source public keys, as described in #4005 and resolved in #4009 (note that this needs to be immediate, as in < 2 seconds)

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 0.12.0
• A message can be successfully submitted

Tails

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