Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

Fix external guest access url for unencrypted rooms #12345

Merged
merged 8 commits into from
Mar 28, 2024

Conversation

toger5
Copy link
Contributor

@toger5 toger5 commented Mar 15, 2024

The external guest url always contained perParticipantE2EE. We do not encrypt calls in unencrypted matrix rooms (if ther room does not have a megolm session there is no good way to get the key material). So the guest SPA should also not use encryption.

Signed-off-by: Timo K toger5@hotmail.de

Checklist

  • Tests written for new code (and old code if feasible).
  • New or updated public/exported symbols have accurate TSDoc documentation.
  • Linter and other CI checks pass.
  • Sign-off given on the changes (see CONTRIBUTING.md).

…compatible with unencrypted embedded calls)

Signed-off-by: Timo K <toger5@hotmail.de>
@toger5 toger5 requested a review from a team as a code owner March 15, 2024 07:23
@toger5 toger5 added the T-Defect Bugs, crashes, hangs, vulnerabilities, or other reported problems label Mar 15, 2024
@@ -279,7 +279,7 @@ export const useRoomCall = (
url.pathname = "/room/";
// Set params for the sharable url
url.searchParams.set("roomId", room.roomId);
url.searchParams.set("perParticipantE2EE", "true");
if (room.hasEncryptionStateEvent()) url.searchParams.set("perParticipantE2EE", "true");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is different from the logic used for the widget URL: https://github.com/matrix-org/matrix-react-sdk/blob/develop/src/models/Call.ts#L784 - the other one seems more correct. Shouldn't they just share a function to decide whether the call is encrypted, and/or some common code to generate the common parts of the URL?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The other one says it's deprecated. Maybe updating both makes sense though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmm, but that says to use CryptoApi.isEncryptionEnabledInRoom instead. I think the problem with just checking for the presence of a state event is that it can be redacted, potentially by a nasty homeserver, but the clients should still treat the room as encrypted. This might let the HS force calls to be unencrypted when they ought to be.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an sync fn however. that would trickle down quiet far. I would need to make Call.get async (because that needs the widget, which needs the widget url parameters that contain on the encryption flag. Is this what we want?
Its also super important, that both clients have the same understanding of the current encryption state of the room. Could CryptoApi remembering that state one one client but another client does not have this information bring this out of sync?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am doing the "use isEncryptionEnabledInRoom" change now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think i found a fix for it: 6c03bb4

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eugh, sorry - I didn't notice this was async, and yes, having Call.get be async is not ideal. Chatting to the crypto team suggests that actually the presence of the state event might be fine after all, so I think whichever you think do whatever you think is best.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated back to not be async and use hasEncryptionStateEvent

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, sorry for the run-around

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no worries. I think it was worth investigating if it can be done using the async fn.

Signed-off-by: Timo K <toger5@hotmail.de>
Signed-off-by: Timo K <toger5@hotmail.de>
@toger5 toger5 added this pull request to the merge queue Mar 28, 2024
Merged via the queue into develop with commit 09f0d11 Mar 28, 2024
22 checks passed
@toger5 toger5 deleted the toger5/fix-link-share-encryption branch March 28, 2024 12:47
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
T-Defect Bugs, crashes, hangs, vulnerabilities, or other reported problems
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants