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

peeking doesn't work over federation #4236

Open
matrixbot opened this issue Dec 16, 2023 · 0 comments
Open

peeking doesn't work over federation #4236

matrixbot opened this issue Dec 16, 2023 · 0 comments

Comments

@matrixbot
Copy link
Collaborator

matrixbot commented Dec 16, 2023

This issue has been migrated from #4236.


The specification states in 13.12

In all cases except world_readable, a user needs to join a room to view events in that room.

It goes on to say:

world_readable - All events while this is the m.room.history_visibility value may be shared by any participating homeserver with anyone, regardless of whether they have ever joined the room.

Exhibited Behavior

Synapse denies world_readable information by imposing a condition which checks if the requesting server has at least one user joined to the room. It responds with the error:

403 Forbidden
{"errcode":"M_FORBIDDEN","error":"Host not in room."}

This is not world_readable as specified. This check occurs on all relevant federation endpoints, making it impossible to access information about a room without joining at least one user. This exhibits a shared rather than world_readable visibility.

Proper Behavior

Synapse should not care whether a requesting server is joined to a room when it attempts to elicit information for events covered by a world_readable visibility state.

Conclusion

As the reference implementation for the specification, this is a problem. Either this is an implementation error by synapse or this is an omission by the written specification. Should server implementations follow suit with synapse de facto or should they follow the specification de jure in contrast with it?

Furthermore, if this condition was implemented to mitigate a security vulnerability, spam or DoS vector, or even a performance problem: other implementations will surely fall victim to it, and the specification should not blindly lead them into doing so. In contrast, if a server developer believes the preceding statement might be true because this discrepancy merely exists, when it is not true, they will degrade the functionality of their server for no reason.

@matrixbot matrixbot changed the title Dummy issue peeking doesn't work over federation Dec 21, 2023
@matrixbot matrixbot reopened this Dec 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant