Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Release SecureDrop Client 0.6.0 #1402

Closed
11 of 26 tasks
sssoleileraaa opened this issue Jan 26, 2022 · 34 comments
Closed
11 of 26 tasks

Release SecureDrop Client 0.6.0 #1402

sssoleileraaa opened this issue Jan 26, 2022 · 34 comments

Comments

@sssoleileraaa
Copy link
Contributor

sssoleileraaa commented Jan 26, 2022 •
edited
Loading

This issue tracks the SecureDrop Client release 0.6.0. It will be organized by:

  • Release Manager: @conorsch
  • Deputy Release Manager: @creviera

This release includes the following changes that will need to be tested as part of this release's test plan:

Other notable changes that are not part of QA:

SecureDrop maintainers and testers: As you QA this release, 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 release milestone for tracking (or ask a maintainer to do so).

Test plan for latest rc of the server

Use the latest rc version of the server on https://apt-test.freedom.press/pool/main/s/securedrop-app-code/, and repeat the test plan below. This helps out with server QA, and if an issue is found, determine if it is a regression caused by the server and report the issue there if it is. Otherwise, report the issue here if it only occurs with the 0.6.0 code.

Test plan

Use the latest production version of the server.

1. Speed up source deletion (#1386)

2. Use /users endpoint for managing journalist accounts (#1397)

  • Follow STR in Deleted user is not fully removed from client database after a sync #1143
    • Confirm you can no longer reproduce the issue
  • Run the client against a local database that already has replies from journalists that have been deleted
  • Close the client and delete a journalist from the admin web UI
    • Confirm the deleted journalist cannot log into the client
  • Stay logged into the client and delete another journalist account from the admin web UI
    • Confirm the journalist no longer exists in the local database after a sync
  • Close the client and add a new journalist from the admin web UI
    • Confirm the new journalist can log into the client
  • Stay logged into the client and create another new journalist account from the admin web UI
    • Confirm the newest journalist exists in the local database after a sync
  • Change the name of the current journalist (change username, firstname, lastname)
    • Confirm change shows up in the journalist badge in upper left-hand corner of the client
    • Confirm change shows up in the journalist badge next to any replies made by this journalist
    • Repeat step above for a journalist that is not currently logged into the client
  • For rc2 (testing this change: Fix 1404 #1412)
    • Create a user with username = "deleteme"
    • Log into the client as the user
    • Stop the tor service on the server that the client is connected to
    • Delete the user in the server database
    • Start the tor service and wait until the client auto reconnects
    • Confirm that the "deleteme" user is logged out once the client can re-establish a connection to the server

3. UI fix to bottom margin in conversation view (#1391)

  • Click on a source to open a conversation that is long enough to show the scrollbar
    • Visually verify that the minimum padding below the last message is the same as the padding above the first message in any given conversation
  • Send a reply to the same source you have selected
    • Visually verify that the minimum padding below the last reply is the same as the padding above the first message in any given conversation

4. Refactors that break up the widgets module into smaller components (#1377-1383, #1390, #1393, #1394)

  • These refactors are covered in the "Basic client regression testing" section

5. Basic client regression testing

Release tasks

  • Update changelog
  • Create test plan

- [ ] Refresh nightlies
- [ ] Begin formal QA using nightlies; refresh nightlies as needed

  • Pause nightlies
  • Publish rc package
  • Begin formal QA using rc package by downloading the deb package from apt-test and installing
  • Build production package in standard build environment
  • Sign production package
  • Perform final pre-flight testing using apt-qa.freedom.press (switch over to apt-qa in sd-app template and run sudo apt update)
    • Localization: In a dispVM, change your locale (e.g.: export LANG=es_ES.utf-8; dpkg-reconfigure locales), run the Client, and confirm that the application is translated.
  • Publish production package
  • Unpause nightlies

- [ ] Publicize release via support channels
@sssoleileraaa sssoleileraaa mentioned this issue Jan 26, 2022
Merged
2 tasks
@sssoleileraaa
Copy link
Contributor Author

@conorsch just so you know where we are in the process, I just opened #1403, so please take a look when you get a chance. We're not at this point yet, but I'd like to double check some things about the process with you, as defined here: https://github.com/freedomofpress/securedrop-debian-packaging#make-a-release

@sssoleileraaa
Copy link
Contributor Author

sssoleileraaa commented Jan 26, 2022 •
edited
Loading

@eloquence, @Kev, and @rocodes (I think you are the QA team for this- I could be wrong), please note that while you could test with nightlies since we paused merges into main, please use the rc debian package on apt-test instead once it's published (I'll give you a heads up when it's ready). Before we publish the rc, we will pause nightlies to ensure we do not clobber your QA environment.

Once the package is on apt-test, remember that you will need to manually run make dev or make staging to get the package, or if you're on a prod instance, switch over to apt-qa in the sd-app template and run sudo apt update (only use apt-qa when testing the final release package).

@eloquence eloquence pinned this issue Jan 26, 2022
@sssoleileraaa
Copy link
Contributor Author

So that everyone is aware, I updated the test plan in the Issue description to include:

@sssoleileraaa sssoleileraaa mentioned this issue Jan 31, 2022
Merged
@eloquence
Copy link
Member

eloquence commented Feb 1, 2022 •
edited
Loading

Environment: Qubes 4.0.4, dev environment, RC1 0.6.0 package, 2.1.0 prod server; also tested with staging workstation environment

1. Speed up source deletion (#1386)

@rocodes
Copy link
Contributor

rocodes commented Feb 1, 2022 •
edited
Loading

Environment:

Qubes 4.0.4 dev env, RC1 0.6.0 package (same as Erik), staging servers; I can test against prod servers tomorrow if desired

1. Speed up source deletion (#1386)

Note I ran into an error deleting a source whose files and msgs had already been deleted, but not the source account itself. However, I think I was just unlucky with a sync error at the wrong time, so I haven't filed an issue.

The 'delete source' animation was visible for about 120 seconds, then visible with a warning (see screenshot), and logs are below.

0-6-0-qa-frozen-delete-2-reconnect

Feb  1 12:11:23 localhost 2022-02-01 12:11:23,582 - securedrop_client.logic:661(on_sync_failure) WARNING: sync failure: The request timed out.
Feb  1 12:13:38 localhost 2022-02-01 12:13:38,491 - securedrop_client.logic:661(on_sync_failure) WARNING: sync failure: The request timed out.
Feb  1 12:13:52 localhost 2022-02-01 12:13:52,762 - securedrop_client.queue:180(process) ERROR: DeleteSourceJobException: Failed to delete source d259e6e1-5f1e-4ca3-8a94-2d733c4edf6f due to WrongUUIDError('Missing source d259e6e1-5f1e-4ca3-8a94-2d733c4edf6f')

2. Use /users endpoint for managing journalist accounts (#1397)

  • Follow STR in Deleted user is not fully removed from client database after a sync #1143
    • Confirm you can no longer reproduce the issue
  • Run the client against a local database that already has replies from journalists that have been deleted
  • Close the client and delete a journalist from the admin web UI
    • Confirm the deleted journalist cannot log into the client
  • Stay logged into the client and delete another journalist account from the admin web UI
    • Confirm the journalist no longer exists in the local database after a sync
  • Close the client and add a new journalist from the admin web UI
    • Confirm the new journalist can log into the client
  • Stay logged into the client and create another new journalist account from the admin web UI
    • Confirm the newest journalist exists in the local database after a sync
  • Change the name of the current journalist (change username, firstname, lastname)

3. UI fix to bottom margin in conversation view (#1391)

  • Click on a source to open a conversation that is long enough to show the scrollbar
    • Visually verify that the minimum padding below the last message is the same as the padding above the first message in any given conversation
  • Send a reply to the same source you have selected
    • Visually verify that the minimum padding below the last reply is the same as the padding above the first message in any given conversation

4. Refactors that break up the widgets module into smaller components (#1377-1383, #1390, #1393, #1394)

  • These refactors are covered in the "Basic client regression testing" section

5. Basic client regression testing

  • Step through https://github.com/freedomofpress/securedrop-client/wiki/QA#basic-client-testing
    • Confirm all checks pass
    • Note: all checks pass, but have 2 more to complete (see below):
    • I can see a pending reply in the client (wget https://gist.githubusercontent.com/creviera/7f19a7d10334359f40dbdbb2354cd13a/raw/a2ef94913a155aa4019b753cf916f844c9cffa3a/pending-reply && git apply pending-reply then send a reply) TODO
    • I can see a failed reply in the client (wget https://gist.githubusercontent.com/creviera/5ba70d50c12b6a6df6f98ed40ad09645/raw/5caef3339ceab1fc997ccb6b9e337bc8828ef12f/failed-reply && git apply failed-reply then send a reply) TODO

@sssoleileraaa sssoleileraaa mentioned this issue Feb 2, 2022
Merged
13 tasks
@eloquence
Copy link
Member

Environment: Qubes 4.0.4, staging environment, RC1 0.6.0 package, 2.1.0 prod server

2. Use /users endpoint for managing journalist accounts (#1397)

  • Follow STR in Deleted user is not fully removed from client database after a sync #1143
    • Confirm you can no longer reproduce the issue
  • Run the client against a local database that already has replies from journalists that have been deleted
  • Close the client and delete a journalist from the admin web UI
    • Confirm the deleted journalist cannot log into the client
  • Stay logged into the client and delete another journalist account from the admin web UI
    • Confirm the journalist no longer exists in the local database after a sync
  • Close the client and add a new journalist from the admin web UI
    • Confirm the new journalist can log into the client
  • Stay logged into the client and create another new journalist account from the admin web UI
    • Confirm the newest journalist exists in the local database after a sync
  • Change the name of the current journalist (change username, firstname, lastname)
    • Confirm change shows up in the journalist badge in upper left-hand corner of the client
    • Confirm change shows up in the journalist badge next to any replies made by this journalist

@eloquence
Copy link
Member

One small observation: When changing the logged in user's name while they were logged in, the observed behavior was as follows:

  1. Client syncs
  2. Reply attribution is updated from "old user" to "new user"
  3. Client syncs
  4. Username badge is updated from "old user" to "new user"

In other words, it took two syncs for the username to be fully updated.

@sssoleileraaa
Copy link
Contributor Author

Note I ran into an error deleting a source whose files and msgs had already been deleted, but not the source account itself. However, I think I was just unlucky with a sync error at the wrong time, so I haven't filed an issue.

The 'delete source' animation was visible for about 120 seconds, then visible with a warning (see screenshot), and logs are below.

@rocodes Please file a report if you can create an STR. Based on your screenshot, it looks like you lost connection with the server during account deletion. I'm not sure if this is the error you are talking about or if there was another error.

@sssoleileraaa
Copy link
Contributor Author

One small observation: When changing the logged in user's name while they were logged in, the observed behavior was as follows:

1. Client syncs

2. Reply attribution is updated from "old user" to "new user"

3. Client syncs

4. Username badge is updated from "old user" to "new user"

In other words, it took two syncs for the username to be fully updated.

@eloquence, I'm unable to repro this in my debian dev env. I'll give it a try again, tomorrow, but if you can take a look at this video maybe you can see that there is a slight different in the way we're both testing this?
2022-02-01 18-56

This was referenced Feb 2, 2022
Closed
Merged
@sssoleileraaa
Copy link
Contributor Author

@eloquence and @rocodes, rc2 is on apt-test, so you can install that package and run through the "For rc2..." test in the test plan

@rocodes
Copy link
Contributor

rocodes commented Feb 2, 2022

Note I ran into an error deleting a source whose files and msgs had already been deleted, but not the source account itself. However, I think I was just unlucky with a sync error at the wrong time, so I haven't filed an issue.
The 'delete source' animation was visible for about 120 seconds, then visible with a warning (see screenshot), and logs are below.

@rocodes Please file a report if you can create an STR. Based on your screenshot, it looks like you lost connection with the server during account deletion. I'm not sure if this is the error you are talking about or if there was another error.

I could not create STR, and I couldn't be sure it was a client issue and not just bad timing (eg memory issue + network sync issue), so I did not file an issue, but I'll let you know if I can reproduce anything similar with rc2.

@rocodes
Copy link
Contributor

rocodes commented Feb 2, 2022

Environment

Qubes 4.0.4 dev env, staging servers, rc2 deb package installed manually.

Test plan

1. Speed up source deletion (#1386)

2. Use /users endpoint for managing journalist accounts (#1397)

  • Follow STR in Deleted user is not fully removed from client database after a sync #1143
    • Confirm you can no longer reproduce the issue
  • Run the client against a local database that already has replies from journalists that have been deleted
  • Close the client and delete a journalist from the admin web UI
    • Confirm the deleted journalist cannot log into the client
  • Stay logged into the client and delete another journalist account from the admin web UI
    • Confirm the journalist no longer exists in the local database after a sync
  • Close the client and add a new journalist from the admin web UI
    • Confirm the new journalist can log into the client
  • Stay logged into the client and create another new journalist account from the admin web UI
    • Confirm the newest journalist exists in the local database after a sync
  • Change the name of the current journalist (change username, firstname, lastname)
    • Confirm change shows up in the journalist badge in upper left-hand corner of the client
    • Confirm change shows up in the journalist badge next to any replies made by this journalist
    • Repeat step above for a journalist that is not currently logged into the client
  • For rc2 (testing this change: Fix 1404 #1412)
    • Create a user with username = "deleteme"
    • Log into the client as the user
    • Stop the tor service on the server that the client is connected to
    • Delete the user in the server database
    • Start the tor service and wait until the client auto reconnects
    • Confirm that the "deleteme" user is logged out once the client can re-establish a connection to the server

3. UI fix to bottom margin in conversation view (#1391)

  • Click on a source to open a conversation that is long enough to show the scrollbar
    • Visually verify that the minimum padding below the last message is the same as the padding above the first message in any given conversation
  • Send a reply to the same source you have selected
    • Visually verify that the minimum padding below the last reply is the same as the padding above the first message in any given conversation

4. Refactors that break up the widgets module into smaller components (#1377-1383, #1390, #1393, #1394)

  • These refactors are covered in the "Basic client regression testing" section

5. Basic client regression testing

@eloquence
Copy link
Member

eloquence commented Feb 3, 2022 •
edited
Loading

Environment: Qubes 4.0.4, staging environment, RC2 0.6.0 package, 2.1.0 prod server

  • For rc2 (testing this change: Fix 1404 #1412)
    • Create a user with username = "deleteme"
    • Log into the client as the user
    • Stop the tor service on the server that the client is connected to
    • Delete the user in the server database
    • Start the tor service and wait until the client auto reconnects
    • Confirm that the "deleteme" user is logged out once the client can re-establish a connection to the server

The client switches into offline mode, the login dialog appears, and I see an error message "Your session expired. Please log in again."

However, after attempting to log back in as a different user (without restarting the app), I get the following error:

2022-02-02 16:40:57,179 - securedrop_client.logic:534(on_authenticate_success) INFO: erik successfully logged in
2022-02-02 16:40:57,193 - root:63(excepthook) ERROR: Unrecoverable error
Traceback (most recent call last):
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/securedrop_client/gui/widgets.py", line 2037, in _on_update_authenticated_user
    if user.uuid == self.sender.uuid:
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/sqlalchemy/orm/attributes.py", line 276, in __get__
    return self.impl.get(instance_state(instance), dict_)
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/sqlalchemy/orm/attributes.py", line 677, in get
    value = state._load_expired(state, passive)
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/sqlalchemy/orm/state.py", line 660, in _load_expired
    self.manager.deferred_scalar_loader(self, toload)
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/sqlalchemy/orm/loading.py", line 985, in load_scalar_attributes
    raise orm_exc.ObjectDeletedError(state)
sqlalchemy.orm.exc.ObjectDeletedError: Instance '<User at 0x70ff1a06bc50>' has been deleted, or its row is otherwise not present.
(END)

Note that I may have sent a reply as the deleteme user before deleting it.

After starting the client again, login works again.

@eloquence
Copy link
Member

Environment: Qubes 4.0.4, staging environment, RC2 0.6.0 package, 2.1.0 prod server

3. UI fix to bottom margin in conversation view (#1391)

  • Click on a source to open a conversation that is long enough to show the scrollbar
    • Visually verify that the minimum padding below the last message is the same as the padding above the first message in any given conversation
  • Send a reply to the same source you have selected
    • Visually verify that the minimum padding below the last reply is the same as the padding above the first message in any given conversation

@rocodes
Copy link
Contributor

rocodes commented Feb 3, 2022 •
edited
Loading

Uhoh. I can repro Erik's issue--I stopped at the end of the deleteme test since it was the last step in the test plan, and only tried logging in with another journalist name this morning to finish QA:

2022-02-03 10:09:14,493 - securedrop_client.logic:534(on_authenticate_success) INFO: dellsberg successfully logged in
2022-02-03 10:09:14,500 - root:63(excepthook) ERROR: Unrecoverable error
Traceback (most recent call last):
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/securedrop_client/gui/widgets.py", line 2037, in _on_update_authenticated_user
    if user.uuid == self.sender.uuid:
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/sqlalchemy/orm/attributes.py", line 276, in __get__
    return self.impl.get(instance_state(instance), dict_)
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/sqlalchemy/orm/attributes.py", line 677, in get
    value = state._load_expired(state, passive)
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/sqlalchemy/orm/state.py", line 660, in _load_expired
    self.manager.deferred_scalar_loader(self, toload)
  File "/opt/venvs/securedrop-client/lib/python3.7/site-packages/sqlalchemy/orm/loading.py", line 985, in load_scalar_attributes
    raise orm_exc.ObjectDeletedError(state)
sqlalchemy.orm.exc.ObjectDeletedError: Instance '<User at 0x767e3efb7dd8>' has been deleted, or its row is otherwise not present.

@sssoleileraaa
Copy link
Contributor Author

Note that there are two test plans now, with the addition of:

Test plan for latest rc of the server

Use the latest rc version of the server on https://apt-test.freedom.press/pool/main/s/securedrop-app-code/, and repeat the test plan below. This helps out with server QA, and if an issue is found, determine if it is a regression caused by the server and report the issue there if it is. Otherwise, report the issue here if it only occurs with the 0.6.0 code.

The latest server rc as of now is rc2.

@eloquence
Copy link
Member

eloquence commented Feb 9, 2022 •
edited
Loading

(Starting a full RC3 test against 2.1.0 server now. I will begin with initializing a fresh 0.5.1 install, to test the upgrade experience as well.)

@eloquence
Copy link
Member

  • Qubes 4.0.4
  • SecureDrop Workstation staging env
  • SD Client 0.6.0 (upgraded from 0.5.1)
  • Server 2.1.0 prod on hardware

1. Speed up source deletion (#1386)

2. Use /users endpoint for managing journalist accounts (#1397)

  • Follow STR in Deleted user is not fully removed from client database after a sync #1143
    • Confirm you can no longer reproduce the issue
  • Run the client against a local database that already has replies from journalists that have been deleted
  • Close the client and delete a journalist from the admin web UI
    • Confirm the deleted journalist cannot log into the client
  • Stay logged into the client and delete another journalist account from the admin web UI
    • Confirm the journalist no longer exists in the local database after a sync
  • Close the client and add a new journalist from the admin web UI
    • Confirm the new journalist can log into the client
  • Stay logged into the client and create another new journalist account from the admin web UI
    • Confirm the newest journalist exists in the local database after a sync
  • Change the name of the current journalist (change username, firstname, lastname)
    • Confirm change shows up in the journalist badge in upper left-hand corner of the client
    • Confirm change shows up in the journalist badge next to any replies made by this journalist
    • Repeat step above for a journalist that is not currently logged into the client

@rocodes
Copy link
Contributor

rocodes commented Feb 9, 2022 •
edited
Loading

Environment

Client @ 0.6.0-rc3 / Staging servers @ 2.2.0-rc2

Test plan

1. Speed up source deletion (#1386)

2. Use /users endpoint for managing journalist accounts (#1397)

  • Follow STR in Deleted user is not fully removed from client database after a sync #1143
    • Confirm you can no longer reproduce the issue
  • Run the client against a local database that already has replies from journalists that have been deleted
  • Close the client and delete a journalist from the admin web UI
    • Confirm the deleted journalist cannot log into the client
  • Stay logged into the client and delete another journalist account from the admin web UI
    • Confirm the journalist no longer exists in the local database after a sync
  • Close the client and add a new journalist from the admin web UI
    • Confirm the new journalist can log into the client
  • Stay logged into the client and create another new journalist account from the admin web UI
    • Confirm the newest journalist exists in the local database after a sync
  • Change the name of the current journalist (change username, firstname, lastname)
    • Confirm change shows up in the journalist badge in upper left-hand corner of the client
      ⚠️ Note: this took two syncs
    • Confirm change shows up in the journalist badge next to any replies made by this journalist
    • Repeat step above for a journalist that is not currently logged into the client
  • For rc2/3 (testing this change: Fix 1404 #1412)
    • Create a user with username = "deleteme"
    • Log into the client as the user
    • Stop the tor service on the server that the client is connected to
    • Delete the user in the server database
    • Start the tor service and wait until the client auto reconnects
    • Confirm that the "deleteme" user is logged out once the client can re-establish a connection to the server

3. UI fix to bottom margin in conversation view (#1391)

  • Click on a source to open a conversation that is long enough to show the scrollbar
    • Visually verify that the minimum padding below the last message is the same as the padding above the first message in any given conversation
  • Send a reply to the same source you have selected
    • Visually verify that the minimum padding below the last reply is the same as the padding above the first message in any given conversation

4. Refactors that break up the widgets module into smaller components (#1377-1383, #1390, #1393, #1394)

  • These refactors are covered in the "Basic client regression testing" section

5. Basic client regression testing

@eloquence
Copy link
Member

  • Qubes 4.0.4
  • SecureDrop Workstation staging env
  • SD Client 0.6.0 (upgraded from 0.5.1)
  • Server 2.1.0 prod on hardware

3. UI fix to bottom margin in conversation view (#1391)

  • Click on a source to open a conversation that is long enough to show the scrollbar
    • Visually verify that the minimum padding below the last message is the same as the padding above the first message in any given conversation
  • Send a reply to the same source you have selected
    • Visually verify that the minimum padding below the last reply is the same as the padding above the first message in any given conversation

4. Refactors that break up the widgets module into smaller components (#1377-1383, #1390, #1393, #1394)

  • These refactors are covered in the "Basic client regression testing" section

5. Basic client regression testing

@eloquence
Copy link
Member

Overall my 2.1.0 testing went well. I didn't end up testing with 2.2.0 since @rocodes already covered that and I decided to focus on reproducing and documenting #1422. That's the only major issue I hit today. As I said on the issue, I'm not sure if that's expected behavior currently; I would recommend at least mentioning it as a known issue in the release comms (basically, if you exit the app abruptly after deleting files, they may linger on disk until you log back in).

@rocodes:

⚠️ Note: this took two syncs

It took me a while today to see that issue again, but eventually I did (with the "stuck permanently" variant), logged as #1423.

Yes, this is a longstanding issue, I see it typically a few times per session when switching between sources.

  • ⚠️ during "I can star and unstar a source and see the same star-state when I log back into the client", if a source is starred and then the journalist signs out quickly afterwards, when they sign in the source is briefly unstarred, and then re-starred after the first sync.

Yes, this is a longstanding issue, which probably warrants tracking as we overall iterate on the sync behavior, similar to the deletion issue above.

@conorsch
Copy link
Contributor

Given consensus in #1422 (comment), I'm going to start preparing the final 0.6.0 release artifacts. We don't plan to release until prod until early next week, but I'll get things in order before then.

@eloquence
Copy link
Member

Thanks @conorsch. I'm pretty confident in the other QA results so far, but I'll do some final exploratory testing against a 2.2.0 server today, as well.

@conorsch conorsch mentioned this issue Feb 10, 2022
Merged
@conorsch conorsch mentioned this issue Feb 10, 2022
Merged
@eloquence
Copy link
Member

eloquence commented Feb 11, 2022 •
edited
Loading

I completed some additional exploratory/end-to-end testing against an RC2 staging server with an RC3 Client. I tested:

  • basic client operations
  • source/conversation deletion
  • deleting users not actively logged in (and monitoring users table)
  • deleting users actively logged in
  • deleting users who have never logged in

Nothing new to report. Once scenario I've not tested that I'm curious about is one where the server is upgraded from 2.1.0 to 2.2.0 and the client already has deleted users in its DB. I may still poke a bit at that before Monday.

@eloquence
Copy link
Member

Did some additional testing of the following migration paths:

  • User deleted on 2.1.0 server → 0.5.1 client syncs with 2.1.0 server → 0.5.1 client upgraded to 0.6.0rc3 → 0.6.0rc3 client syncs with 2.1.0 server → server upgraded to 2.2.0rc2 → 0.6.0rc3 client syncs with 2.2.0rc2 server
  • User deleted on 2.1.0 server → 0.5.1 client syncs with 2.1.0 server → server upgraded to 2.2.0rc2 → 0.5.1 client upgraded to 0.6.0rc3 → 0.6.0rc3 client syncs with 2.2.0rc2 server

Both were handled without errors, only a single deleted user existed in the client database, and the deleted user reply association was preserved.

@eloquence
Copy link
Member

Per chat today, we'll back out #1386 for now (to reduce time pressure for a proper fix and avoid expanding the scope of #1422), cut RC4, run through QA (may be slightly abbreviated), and if all looks good, release tomorrow or Wednesday. I'll take point for some QA today, starting with 2.1.0 server.

@conorsch conorsch mentioned this issue Feb 14, 2022
Merged
@eloquence
Copy link
Member

We have an RC4, proceeding with QA against 2.1.0.

@eloquence
Copy link
Member

  • Qubes 4.0.4 staging env
  • SecureDrop Client 0.6.0 RC4
  • SD 2.1.0 prod server

1. Speed up source deletion (#1386)

This was reverted. I tested that deletion still behaves as before, which it does:

@eloquence
Copy link
Member

  • Qubes 4.0.4 staging env
  • SecureDrop Client 0.6.0 RC4
  • SD 2.1.0 prod server

2. Use /users endpoint for managing journalist accounts (#1397)

  • Follow STR in Deleted user is not fully removed from client database after a sync #1143
    • Confirm you can no longer reproduce the issue
  • Run the client against a local database that already has replies from journalists that have been deleted
  • Close the client and delete a journalist from the admin web UI
    • Confirm the deleted journalist cannot log into the client (skipped)
  • Stay logged into the client and delete another journalist account from the admin web UI
    • Confirm the journalist no longer exists in the local database after a sync
  • Close the client and add a new journalist from the admin web UI
    • Confirm the new journalist can log into the client
  • Stay logged into the client and create another new journalist account from the admin web UI
    • Confirm the newest journalist exists in the local database after a sync
  • Change the name of the current journalist (change username, firstname, lastname)
    • Confirm change shows up in the journalist badge in upper left-hand corner of the client
    • Confirm change shows up in the journalist badge next to any replies made by this journalist
    • Repeat step above for a journalist that is not currently logged into the client
  • For rc2 (testing this change: Fix 1404 #1412)
    • Create a user with username = "deleteme"
    • Log into the client as the user
    • Stop the tor service on the server that the client is connected to
    • Delete the user in the server database
    • Start the tor service and wait until the client auto reconnects
    • Confirm that the "deleteme" user is logged out once the client can re-establish a connection to the server

3. UI fix to bottom margin in conversation view (#1391)

  • Click on a source to open a conversation that is long enough to show the scrollbar
    • Visually verify that the minimum padding below the last message is the same as the padding above the first message in any given conversation
  • Send a reply to the same source you have selected
    • Visually verify that the minimum padding below the last reply is the same as the padding above the first message in any given conversation

4. Refactors that break up the widgets module into smaller components (#1377-1383, #1390, #1393, #1394)

  • These refactors are covered in the "Basic client regression testing" section

5. Basic client regression testing

@eloquence
Copy link
Member

eloquence commented Feb 15, 2022 •
edited
Loading

Qubes 4.0.4 staging env, SecureDrop Client 0.6.0 RC4, SD 2.2.0 RC2 staging server:

  • Deleting sources and conversations works as expected (i.e. 0.5.1-equivalent)
  • Repeatedly deleting users works as expected (known issue: "deleted" icon sometimes takes an extra couple of seconds to be rendered, initially the placeholder is sometimes blank)
  • Updating usernames works as expected

What I've not tested in this run (but did test previously) is the 0.5.1 on 2.1.0->0.6.0 on 2.10->0.6.0 on 2.2.0 behavior for deleted users.

@rocodes If you have cycles for additional testing, my recommendation would be to spend them on those migration paths; overall though, I'm pretty confident that the revert did not impact other app behavior, and we've already thoroughly tested previous RCs.

I've actually not encountered #1343 again since testing with RC4, though my understanding is that we expect to see it again as a result of #1426.

@conorsch conorsch mentioned this issue Feb 15, 2022
Merged
@rocodes
Copy link
Contributor

rocodes commented Feb 15, 2022

Environment:
Qubes 4.0.4, 0.5.1 client against 2.1.0 servers ugpraded to 0.6.0-rc4 against 2.2.0-rc2 servers

2. Use /users endpoint for managing journalist accounts (#1397)

  • Follow STR in Deleted user is not fully removed from client database after a sync #1143
    • Confirm you can no longer reproduce the issue
  • Run the client against a local database that already has replies from journalists that have been deleted
  • Close the client and delete a journalist from the admin web UI
    • Confirm the deleted journalist cannot log into the client
  • Stay logged into the client and delete another journalist account from the admin web UI
    • Confirm the journalist no longer exists in the local database after a sync
  • Close the client and add a new journalist from the admin web UI
    • Confirm the new journalist can log into the client
  • Stay logged into the client and create another new journalist account from the admin web UI
    • Confirm the newest journalist exists in the local database after a sync
  • Change the name of the current journalist (change username, firstname, lastname)
    • Confirm change shows up in the journalist badge in upper left-hand corner of the client
    • Confirm change shows up in the journalist badge next to any replies made by this journalist
    • Repeat step above for a journalist that is not currently logged into the client
  • For rc2 (testing this change: Fix 1404 #1412)
    • Create a user with username = "deleteme"
    • Log into the client as the user
    • Stop the tor service on the server that the client is connected to
    • Delete the user in the server database
    • Start the tor service and wait until the client auto reconnects
    • Confirm that the "deleteme" user is logged out once the client can re-establish a connection to the server

@eloquence
Copy link
Member

I was able to install the package from apt-qa successfully and performed basic smoke testing. Locale strings also are loading correctly - this is the login in screen in German:
german-login

@eloquence
Copy link
Member

eloquence commented Feb 15, 2022 •
edited
Loading

SecureDrop Client 0.6.0 was released on 2022-02-15, with the source deletion-related changes backed out for now.

@eloquence eloquence unpinned this issue Feb 15, 2022
@sssoleileraaa
Copy link
Contributor Author

freedomofpress/securedrop-builder#294 was merged so this can now really closed ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@eloquence @conorsch @sssoleileraaa @rocodes