Skip to content

Fix logic in DeviceListener #30230

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.

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

Merged

Conversation

uhoreg
Copy link
Member

@uhoreg uhoreg commented Jun 29, 2025

Fixes #29883

SETUP_ENCRYPTION tried to set up all of encryption (4S, cross-signing, key backup), but we now have it split into different stages, so it is obsolete.

Review commit-by-commit

Checklist

  • Tests written for new code (and old code if feasible).
  • New or updated public/exported symbols have accurate TSDoc documentation.
  • Linter and other CI checks pass.
  • I have licensed the changes to Element by completing the Contributor License Agreement (CLA)

uhoreg added 4 commits June 28, 2025 23:03
SETUP_ENCRYPTION tries to set up everything (4S, cross-signing and key backup),
rather than just setting up encryption, as its name would imply.
crossSigningReady == false happens when the user's device isn't verified, so it
should trigger VERIFY_THIS_SESSION rather than SETUP_ENCRYPTION
rather than falling back to the SETUP_ENCRYPTION catch-all.  Also, remove
SETUP_ENCRYPTION since it is no longer used.
(almost) all the other functions that use make decisions based on Kind use
switch statements
Copy link
Member

@andybalaam andybalaam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. I answered my own question later in the review, so I think it all makes sense.

Copy link
Member

@dbkr dbkr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, think this looks sensible, thanks.

@uhoreg uhoreg added this pull request to the merge queue Jun 30, 2025
Merged via the queue into element-hq:develop with commit 3d56aa7 Jun 30, 2025
41 of 43 checks passed
@uhoreg uhoreg deleted the device_listener_encryption_toast_refactor branch June 30, 2025 14:16
});
showSetupEncryptionToast(SetupKind.SET_UP_ENCRYPTION);
// If we get here, then we are verified, have key backup, and
// 4S, but crypto.isCrossSigningReady returned false, which
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

crypto.isCrossSigningReady returned false

Are you sure this is the only way we can get here?

For example, what happens if isCrossSigningReady returns true, but isSecretStorageReady returns false?

In any case, please can you keep the logic to log all the flags, so that we can debug why we are falling into the else case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh. I typo'ed the comment. It should say "but crypto.isSecretStorageReady returned false". (If isCrossSigningReady returns false, then isCurrentDeviceTrusted will be false and we'll run the first branch of the if statement.) I'll make a new PR to fix the comment and reinstate the logging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Toast when unverified is, "Set up secure backup"
4 participants