Use a more structured algorithm for determining decryption client for appservice events #41
Conversation
Half-Shot
force-pushed
the
hs/intelligent-decrypt
branch
from
aa8e470
to
15643f8
Compare
| private async decryptAppserivceEvent(roomId: string, encrypted: EncryptedRoomEvent): ReturnType<Appservice["processEvent"]> { | ||
| const existingClient = this.cryptoClientForRoomId.get(roomId); | ||
| const decryptFn = async (client: MatrixClient) => { | ||
| let event = (await client.crypto.decryptRoomEvent(encrypted, roomId)).raw; |
There was a problem hiding this comment.
If the rust-sdk's OlmMachine doesn't discard keys for rooms that a user has left, then this should first check if client is currently in the target room. Otherwise, this would decrypt an event that client shouldn't be able to access.
On the other hand, it might not matter in practice whether client shouldn't see the event, because as long as any of the appservice's users can see it, there's no difference in terms of privacy/security which of its clients the appservices uses to decrypt an event.
There was a problem hiding this comment.
I don't think we materially care on the AS side. If we still have keys and can turn an encrypted body into unencrypted text then yay. It doesn't really matter which client did it.
This PR changes the way we pick a client for decrypting an event, and caches the result so that it can be reused. This is intended to ensure that when the sender user isn't used for decryption, Appservice doesn't make repeated calls to get_joined_rooms, and when it picks a client it prefers one with encryption already enabled to save time.
We also update to ES2022 so I can use Error.cause, one of my favourite new ES features.
Checklist