-
Notifications
You must be signed in to change notification settings - Fork 246
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
crypto: Don't deep copy the OlmMachine when creating a notification client #3992
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3992 +/- ##
==========================================
- Coverage 84.26% 84.25% -0.02%
==========================================
Files 266 266
Lines 28332 28336 +4
==========================================
- Hits 23875 23874 -1
- Misses 4457 4462 +5 ☔ View full report in Codecov by Sentry. |
2e96459
to
d4c51d6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing catch, thanks for writing a test too. I'll send you my best baguette over mail.
crates/matrix-sdk-ui/tests/integration/encryption_sync_service.rs
Outdated
Show resolved
Hide resolved
crates/matrix-sdk-ui/tests/integration/encryption_sync_service.rs
Outdated
Show resolved
Hide resolved
3635fe4
to
f32a795
Compare
f32a795
to
5db87b5
Compare
…nClient The NotificationClient, responsible for handling, fetching, and potentially decrypting events received via push notifications, creates a copy of the main Client object. During this process, the Client object is adjusted to use an in-memory state store to prevent concurrency issues from multiple sync loops attempting to write to the same database. This copying unintentionally recreated the OlmMachine with fresh data loaded from the database. If both Client instances were used for syncing without proper cross-process locking, forks of the vodozemac Account and Olm Sessions could be created and later persisted to the database. This behavior can lead to the duplication of one-time keys, cause sessions to lose their ability to decrypt messages, and result in the generation of undecryptable messages on the recipient’s side.
5db87b5
to
f590543
Compare
Opening as a draft since I will want to make test for this. This closes: #1415.