Page MenuHomePhabricator

[lib] handle race condition when creating `olm` session
ClosedPublic

Authored by kamil on Tue, Apr 9, 4:45 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 27, 10:33 PM
Unknown Object (File)
Wed, Apr 24, 2:16 PM
Unknown Object (File)
Mon, Apr 22, 10:21 AM
Unknown Object (File)
Mon, Apr 22, 7:41 AM
Unknown Object (File)
Sun, Apr 21, 1:11 AM
Unknown Object (File)
Tue, Apr 16, 2:07 PM
Unknown Object (File)
Tue, Apr 16, 12:13 PM
Unknown Object (File)
Tue, Apr 16, 11:19 AM
Subscribers

Details

Summary

This is the code that chooses which session to keep and which to reset.

When there is a race condition and the device has a higher deviceID - ignore the request (the other device will get our session request and then decide to accept the session as it has a lower deviceID). Already queued messages can be ignored, while decrypting we will get OLM_SENDER_CHAIN_NOT_ACKNOWLEDGED which is different than BAD_MESSAGE_MAC so those messages will not cause a resetting session again.

When there is a race condition and the device has a lower deviceID - overwrite session and resend all messages, there is a separate task to work on this (see comment).

Depends on D11595

Test Plan
  1. Create two new devices.
  2. Hardcode session versions (high value).
  3. Send session request - should be created.
  4. Send session request again - this simulates race condition (one device already have session with ID and receives request with the same ID).
  5. Device should ignore it to accept depending on deviceID - tested both cases.

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kamil held this revision as a draft.
This revision is now accepted and ready to land.Thu, Apr 11, 1:00 AM