Skip to content
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

Don't specify an invalid "join_authorised_via_users_server" key for a test that doesn't require it #224

Closed
wants to merge 1 commit into from

Conversation

neilalexander
Copy link
Contributor

This breaks the signature checks in gomatrixserverlib/dendrite, because we expect the "join_authorised_via_users_server" key to be well-formed so we can extract the server name.

… a test that doesn't require it

This breaks the signature checks in gomatrixserverlib/dendrite, because we expect the `"join_authorised_via_users_server"` key to be well-formed so we can extract the server name.
@clokep
Copy link
Member

clokep commented Nov 15, 2021

I'm unsure about this change, it was added in #208 as a regression test against something which was actually happening in the wild (clients were including that additional field when changing nicknames for rooms). I think for the test to be accurate it really needs the field to be included, not just missing -- although we might actually want to test both situations.

Changing the value so it can be parsed (instead of the wrong form) is likely OK, but shouldn't gomatrixserverlib bet treating this as "untrusted data" and not assuming it is well-formed?

@neilalexander
Copy link
Contributor Author

shouldn't gomatrixserverlib bet treating this as "untrusted data" and not assuming it is well-formed?

gomatrixserverlib can only require the extra signature from the authorising server in the event auth if it can parse the server name from that field. If we fail to parse then we can’t add the second “needed” server name for the signature checking, which would result in the event possibly passing the signature checks when it otherwise shouldn’t.

The ”join_authorised_via_users_server” field isn’t specced as opaque so it isn’t clear what to do here otherwise?

https://github.com/matrix-org/gomatrixserverlib/blob/master/eventcrypto.go#L85-L96

@clokep
Copy link
Member

clokep commented Nov 15, 2021

gomatrixserverlib can only require the extra signature from the authorising server in the event auth if it can parse the server name from that field.

This test-case is testing that the extra signature isn't needed since it is a join -> join transition.

@neilalexander
Copy link
Contributor Author

This test-case is testing that the extra signature isn't needed since it is a join -> join transition.

I am guessing then that Synapse needs to tangle the signature checking and event auth checks together for this to work? That is not how gomatrixserverlib works (Dendrite and GMSL on the whole are much more compartmentalised out of necessity) and this is obviously why things are ending up so difficult to implement.

@clokep
Copy link
Member

clokep commented Nov 15, 2021

I think what is missing here is that Synapse strips any join_authorised_via_users_server received over the client-server API (see matrix-org/synapse#10933 and the corresponding issue). I think we considered this an implementation detail, which is why it isn't part of the MSC, but clearly testing for that in complement doesn't necessarily make sense then.

I think it is necessary though for /myroom{nick,avatar} to work properly.

@clokep
Copy link
Member

clokep commented Nov 18, 2021

I think what is missing here is that Synapse strips any join_authorised_via_users_server received over the client-server API (see matrix-org/synapse#10933 and the corresponding issue). I think we considered this an implementation detail, which is why it isn't part of the MSC, but clearly testing for that in complement doesn't necessarily make sense then.

I think it is necessary though for /myroom{nick,avatar} to work properly.

I brought this up on the spec PR: matrix-org/matrix-spec-proposals#3387.

@clokep clokep removed their request for review November 23, 2021 12:41
@kegsay
Copy link
Member

kegsay commented Dec 8, 2021

So what's the status of this PR? Is it good and should be merged or does it test something we don't allow?

@clokep
Copy link
Member

clokep commented Dec 8, 2021

So what's the status of this PR? Is it good and should be merged or does it test something we don't allow?

I believe this PR is weakening a test that will likely cause Dendrite (and other homeservers) to break under the same conditions that Synapse did.

@kegsay
Copy link
Member

kegsay commented Dec 15, 2021

Closing this for now then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants