This differential modifies utility function that creates content session to create both content and notif sessions idempotently
Details
- Apply this stash: https://gist.github.com/marcinwasowicz/047b0f1b00079562b2547ebe3a8c18ad. This stash does some of the work https://linear.app/comm/project/send-encrypted-notification-from-the-client-to-the-tunnelbroker-03fc019ed3ee/issues is supposed to do. Message reducer is modified to return MessageData array and db-ops-handler greedily consumes MessageData array to create and send encrypted notifications through TB.
- Send text message from a client (any platform).
- Ensure that the first time you send message there are logs indicating that session are created with particular device ids (thread members device ids).
- Ensure that each time you see in the console logged payloads of encrypted notifications. Examine payloads. Ensure that they match relevant flow types. No notification will be displayed on the receiving client since they can't decrypt the notif yet.
Diff Detail
- Repository
- rCOMM Comm
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
I am afraid that there is a vulnerability in this diff. Basically it is possible that two createOlmSessionWithPeer promises will execute concurrently. This might lead to corrupted state. In order to mitigate that I think it is best expose this method as a context. The context would internally keep a map like [(userID, deviceID)] : Promise mapping from particular deviceID and userID to currently executing promise (if any).
Sounds like something that should be fixed.
lib/utils/crypto-utils.js | ||
---|---|---|
161–171 ↗ | (On Diff #42043) | It is possible that hasNotifsSession is true here - should we create the notifs session regardless? |
lib/utils/crypto-utils.js | ||
---|---|---|
161–171 ↗ | (On Diff #42043) | Perhaps I am missing something but I think that if we reach these lines then we are in the case that there are neither notifs nor content session. If statement at liner 126 should guarantee this |
lib/utils/crypto-utils.js | ||
---|---|---|
161–171 ↗ | (On Diff #42043) | If hasContentSession = false and hasNotifsSession = true, then we won't enter the if at 126 line. We also won't enter the if at 152. So it seems possible to reach this code with the session present. |
This diff looks confusing to me. We're introducing a new context PeerOlmSessionCreatorContext but it doesn't look like we're using it.
lib/components/peer-olm-session-creator-provider.react.js | ||
---|---|---|
35–38 ↗ | (On Diff #42348) | This looks fragile. We have a function that accepts two parameters but keep promises in an object indexed by only one of them. What if someone calls this method twice with the same deviceID and with different userIDs? We can solve this issue in two ways: 1. we can index by two properties, or 2. we can remove userID parameter and get it from e.g. a selector. Not sure which is better, but in the second solution we should probably also clear the runningPromises ref. Or maybe, userID here means the ID of a user possessing a device with deviceID. If that's correct, we're fine with the current solution. |
- Use query to check notifications session for multiple devices at once and initilize crypto account in send utils instead of each time before encryption. it is huge performance improvement.
- Fix context cycle
@marcin can you please respond to this? What is the point of this new PeerOlmSessionCreatorContext? Please explain things like this in diff descriptions, and please make sure you always document any offline discussions in response to diff comments on that diff.
@marcin can you please respond to this?
I responded by replacing usages of createOlmSessionWithPeer with context usages.
What is the point of this new PeerOlmSessionCreatorContext?
Everything was explained here and reviewers were aware of this.
Please explain things like this in diff descriptions, and please make sure you always document any offline discussions in response to diff comments on that diff.
There was no undocumented offline discussion regarding this diff.
Thanks @marcin! Can you link the diff where the context is used? Appreciate your explanation above!