-
Notifications
You must be signed in to change notification settings - Fork 493
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
The push extension sometimes breaks e2e #3817
Milestone
Comments
manuroe
added
T-Defect
Something isn't working: bugs, crashes, hangs and other reported problems
feature:e2e
P1
labels
Nov 18, 2020
manuroe
added a commit
to matrix-org/matrix-ios-sdk
that referenced
this issue
Nov 19, 2020
to avoid race conditions across multiple processes (element-hq/element-ios#3817) where a race can rewind back the state of the OLMAccont into the DB. Logging as been improved a bit to better track olm session issues
manuroe
added a commit
to matrix-org/matrix-ios-sdk
that referenced
this issue
Nov 19, 2020
to avoid race conditions across multiple processes (element-hq/element-ios#3817) where a race can rewind back the state of the OLMAccont into the DB. Logging as been improved a bit to better track olm session issues
manuroe
added a commit
to matrix-org/matrix-ios-sdk
that referenced
this issue
Nov 19, 2020
to avoid race conditions across multiple processes (element-hq/element-ios#3817) where a race can rewind back the state of the OLMAccont into the DB. Logging as been improved a bit to better track olm session issues
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We mitigate OTK duplicates (#3721) with matrix-org/matrix-ios-sdk#922 without solving the root issue which is a race condition between the app and the NotificationServiceExtension.
Since iOS 13 (June 2020), pushes cannot be managed anymore by the main app in the background. They must be managed by a separated extension, NotificationServiceExtension, which is a background service that has its own life cycle.
To be able to decrypt message content, the notification extension needs to have a minimal set of crypto available. Most of things are done in an atomic way but not everything which is a problem when the app is running in parallel.
One issue is that both modules have their own instance of OLMAccount loaded in memory. They can both decide to store their OLMAccount instance in the DB at anytime, overwriting what the other stored.
The NotificationServiceExtension does it when receiving a new inbound olm session. When it happens, there is a high risk that it will store an older version of the olm account that the app has. This newly stored olm account will ignore OTK that was sent by the app for example.
There is possibly other issues related to this multi-process access but we need to make
MXOlmDevice.olmAccount
atomic.The text was updated successfully, but these errors were encountered: