Release SecureDrop 1.0.0 #4724
Comments
Clean install - VMs with V3 onion URLs (Complete)Environment
Basic Server Testing
Command Line User Generation
Administration
Application Acceptance TestingSource InterfaceLanding page base cases
First submission base cases
Returning source base cases
Journalist InterfaceLogin base cases
Index base cases
Individual source page
Basic Tails TestingUpdater GUIAfter updating to this release candidate and running
1.0.0-specific changesNote that it is not expected that a single tester test each one of the Tor onion services scenarios, please just indicate which scenarios you covered in the comment on the release ticket and the row at the end of the QA matrix (please fill the QA matrix in as you begin QA such that work is not duplicated). From a 1.0.0 install: Tor onion services: upgrade to v2
Tor onion services: upgrade to v2+v3Precondition:
Tor onion service: v3 only, no HTTPS
❗ Note: I don't recall the install run throwing a timeout when running ./securedrop-admin install to disable ssh over tor: Tor onion service: adding v3 interfaces with SSH over LAN
Deletion functionality
Testing detection and correction of disconnected submissionsVisit the source interface and send two messages. First we'll test a disconnected database record. In your You should see the two message files. Remove one with rm.
Now we'll delete the remaining database record and verify that its disconnected file is detected. Still in your Delete the submission record for the remaining message (substitute your filename):
Testing automatic requeuing of interrupted deletionsEstablish two SSH connections to the app server. In one, become root with Activate the securedrop-app-code virtualenv:
Create a big file that will take a while to delete: Submit a job to delete it: Exit Python. In the root shell: Look at the rqrequeue log: less /var/log/securedrop_worker/rqrequeue.err -- at the end you should see lines like this: That indicates the interrupted job was found and restarted, but was left alone at the next check because it was already running. The job should run to completion,
Testing OSSEC reporting of disconnectsCreate a file under
Miscellaneous other changes
❗ supervisor uses system python but that's because it's managed upstream:
|
|
WIP pre-release messaging here, first comments welcome: https://docs.google.com/document/d/1Rc7Z-WsFZUWjTaDGta2_lz4MBo51Tb4Z49GQPPOSM4I/edit# |
QA plan
1.0.0 QA ChecklistFor 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.0.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 1.0.0-specific changes as well as changes since the previous release candidate. Environment
Basic Server Testing
Command Line User Generation
Administration
Application Acceptance TestingSource InterfaceLanding page base cases
First submission base cases
Returning source base cases
Journalist InterfaceLogin base cases
Index base cases
Individual source page
Basic Tails TestingUpdater GUIAfter updating to this release candidate and running
1.0.0-specific changesNote that it is not expected that a single tester test each one of the Tor onion services scenarios, please just indicate which scenarios you covered in the comment on the release ticket and the row at the end of the QA matrix (please fill the QA matrix in as you begin QA such that work is not duplicated). From a 1.0.0 install: Tor onion services: upgrade to v2
Tor onion services: upgrade to v2+v3Precondition:
Tor onion service: v3 only, no HTTPS
Tor onion service: adding v3 interfaces with SSH over LAN
Deletion functionality
Testing detection and correction of disconnected submissionsVisit the source interface and send two messages. First we'll test a disconnected database record. In your You should see the two message files. Remove one with rm.
Now we'll delete the remaining database record and verify that its disconnected file is detected. Still in your Delete the submission record for the remaining message (substitute your filename):
Testing automatic requeuing of interrupted deletionsEstablish two SSH connections to the app server. In one, become root with Activate the securedrop-app-code virtualenv:
Create a big file that will take a while to delete: Submit a job to delete it: Exit Python. In the root shell: Look at the rqrequeue log: less /var/log/securedrop_worker/rqrequeue.err -- at the end you should see lines like this: That indicates the interrupted job was found and restarted, but was left alone at the next check because it was already running. The job should run to completion,
Testing OSSEC reporting of disconnectsCreate a file under
Miscellaneous other changes
Preflight
These tests should be performed the day of release prior to live debian packages on apt.freedom.press Basic testing
Tails
|
1.0.0 QA ChecklistEnvironment
Basic Server Testing
Command Line User Generation
Administration
Application Acceptance TestingSource InterfaceLanding page base cases
First submission base cases
Returning source base cases
Journalist InterfaceLogin base cases
Index base cases
Individual source page
Basic Tails TestingUpdater GUIAfter updating to this release candidate and running
1.0.0-specific changesFrom a 1.0.0 install: Tor onion services: Fresh install on v2 (used a site-specific from the previous release and did not re-run sdconfig)[I DID NOT TEST]
Testing detection and correction of disconnected submissions(also made a reply before all this to test #4734)
Testing automatic requeuing of interrupted deletions
Testing OSSEC reporting of disconnectsCreate a file under
Miscellaneous other changes
|
|
Pre-release announcement is live: Tweeted here: Redmine bulk distribution completed. |
QA plan IN PROGRESS
1.0.0 QA ChecklistFor 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.0.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 1.0.0-specific changes as well as changes since the previous release candidate. Environment
Basic Server Testing
Command Line User Generation
Administration
Application Acceptance TestingSource InterfaceLanding page base cases
First submission base cases
Returning source base cases
Journalist InterfaceLogin base cases
Index base cases
Individual source page
Basic Tails TestingUpdater GUIAfter updating to this release candidate and running
1.0.0-specific changesNote that it is not expected that a single tester test each one of the Tor onion services scenarios, please just indicate which scenarios you covered in the comment on the release ticket and the row at the end of the QA matrix (please fill the QA matrix in as you begin QA such that work is not duplicated). From a 1.0.0 install: Tor onion services: upgrade to v2
Tor onion services: upgrade to v2+v3Precondition:
Tor onion service: v3 only, no HTTPS
Tor onion service: adding v3 interfaces with SSH over LAN
Deletion functionality
Testing detection and correction of disconnected submissionsVisit the source interface and send two messages. First we'll test a disconnected database record. In your You should see the two message files. Remove one with rm.
Now we'll delete the remaining database record and verify that its disconnected file is detected. Still in your Delete the submission record for the remaining message (substitute your filename):
Testing automatic requeuing of interrupted deletionsEstablish two SSH connections to the app server. In one, become root with Activate the securedrop-app-code virtualenv:
Create a big file that will take a while to delete: Submit a job to delete it: Exit Python. In the root shell: Look at the rqrequeue log: less /var/log/securedrop_worker/rqrequeue.err -- at the end you should see lines like this: That indicates the interrupted job was found and restarted, but was left alone at the next check because it was already running. The job should run to completion,
Testing OSSEC reporting of disconnectsCreate a file under
Miscellaneous other changes
Preflight
These tests should be performed the day of release prior to live debian packages on apt.freedom.press Basic testing
Tails
|
Environment
Basic Server Testing
Command Line User Generation
Administration
Application Acceptance TestingSource InterfaceLanding page base cases
First submission base cases
Returning source base cases
Journalist InterfaceLogin base cases
Index base cases
Individual source page
Basic Tails TestingUpdater GUIAfter updating to this release candidate and running
Deletion functionality
Testing detection and correction of disconnected submissionsVisit the source interface and send two messages. First we'll test a disconnected database record. In your You should see the two message files. Remove one with rm.
Now we'll delete the remaining database record and verify that its disconnected file is detected. Still in your Delete the submission record for the remaining message (substitute your filename):
Testing automatic requeuing of interrupted deletionsEstablish two SSH connections to the app server. In one, become root with Activate the securedrop-app-code virtualenv:
Create a big file that will take a while to delete: Submit a job to delete it: Exit Python. In the root shell: Look at the rqrequeue log: less /var/log/securedrop_worker/rqrequeue.err -- at the end you should see lines like this: That indicates the interrupted job was found and restarted, but was left alone at the next check because it was already running. The job should run to completion,
Testing OSSEC reporting of disconnectsCreate a file under
Design changes:
Miscellaneous other changes
|
|
Draft release messaging: |
Environment
NOTE: Skipped basic server and application and some upgrade tests; will do those in rc4 cron-apt upgrade scenario. 1.0.0-specific changesNote that it is not expected that a single tester test each one of the Tor onion services scenarios, please just indicate which scenarios you covered in the comment on the release ticket and the row at the end of the QA matrix (please fill the QA matrix in as you begin QA such that work is not duplicated). From a 1.0.0 install: Tor onion services: upgrade to v2+v3Precondition:
Tor onion service: v3 only, no HTTPS
Deletion functionalityTesting detection and correction of disconnected submissionsVisit the source interface and send two messages. First we'll test a disconnected database record. In your You should see the two message files. Remove one with rm.
Now we'll delete the remaining database record and verify that its disconnected file is detected. Still in your Delete the submission record for the remaining message (substitute your filename):
Testing automatic requeuing of interrupted deletionsEstablish two SSH connections to the app server. In one, become root with Activate the securedrop-app-code virtualenv:
Create a big file that will take a while to delete: Submit a job to delete it: Exit Python. In the root shell: Look at the rqrequeue log: less /var/log/securedrop_worker/rqrequeue.err -- at the end you should see lines like this: That indicates the interrupted job was found and restarted, but was left alone at the next check because it was already running. The job should run to completion,
Testing OSSEC reporting of disconnectsCreate a file under
Design changes:
Miscellaneous other changes
|
|
Release blog post: Tweet: All Redmine instances notified and previous pre-release messaging closed out. |
|
Final item on the checklist was closed in #4857 |
That task was assigned to me, and I neglected to complete it during final release procedures. For future reference, the procedure is documented here: https://github.com/freedomofpress/securedrop/wiki/Build-logs |
This is a tracking issue for the upcoming release of SecureDrop 1.0.0 - tasks may get added or modified.
String and feature freeze: 2019-08-29 (1700 PDT)
String comment period: 2019-08-29 (1700 PDT) to 2019-09-02 (2000 PDT)
Feature freeze: 2019-08-30 (1700 PDT) (release branch will be cut AM Eastern time on September 3rd)
Translation period: 2019-09-03 (1700 PDT) to 2019-09-15 (1700 PDT)
Pre-release announcement: 2019-09-10
Translation freeze: 2019-09-15 (1700 PDT)
Release date: 2019-09-17
Release manager: @kushaldas
Deputy release manager: @emkll
Localization manager: @rmol
Deputy localization manager: @redshiftzero
SecureDrop maintainers and testers: As you QA 1.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 1.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 1.0.0
Test Plan for 1.0.0
Prepare release candidate (1.0.0~rc1)
1.0.0~rc1on test apt server (this is now done via a PR into this repository) - @emkllOther pre-release tasks
Prepare release candidate (1.0.0~rc2)
1.0.0~rc2on test apt server - @kushaldasNote: For SecureDrop 1.0.0, we will cut at least two release candidates. Additional release candidates may follow if issues are found in rc2.
Prepare release candidate (1.0.0~rc3)
1.0.0~rc3on test apt server - @kushaldasAfter each test, please update the QA matrix and post details for Basic Server Testing, Application Acceptance Testing and 1.0.0-specific testing below in comments to this ticket.
Final release
Post release
develop@kushaldas backport changelog entries from 1.0.0 and updates to 1.1.0~rc1 #4840developin prep for 1.1.0 release @kushaldas backport changelog entries from 1.0.0 and updates to 1.1.0~rc1 #4840The text was updated successfully, but these errors were encountered: