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

peeking doesn't work over federation #4236

Open
Tracked by #3506
jevolk opened this issue Nov 28, 2018 · 2 comments
Open
Tracked by #3506

peeking doesn't work over federation #4236

jevolk opened this issue Nov 28, 2018 · 2 comments
Labels
A-Spec-Compliance places where synapse does not conform to the spec O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.

Comments

@jevolk
Copy link

jevolk commented Nov 28, 2018

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.

@jevolk jevolk changed the title "Host not in room" is not specified and improper behavior. world_readable is not world readable Nov 28, 2018
@neilisfragile neilisfragile added z-bug (Deprecated Label) z-p2 (Deprecated Label) labels Nov 30, 2018
@neilisfragile
Copy link
Contributor

Synapse bug, spec describes the correct behaviour.

@ara4n
Copy link
Member

ara4n commented Apr 21, 2019

I think this is effectively a dup or very closely related to https://github.com/matrix-org/matrix-doc/issues/913. It's not clear what endpoints this bug is actually concerned about though (/sync, /events, or SS API queries?)

@richvdh richvdh changed the title world_readable is not world readable peeking doesn't work over federation Feb 26, 2020
@clokep clokep added the A-Spec-Compliance places where synapse does not conform to the spec label Apr 29, 2020
@erikjohnston erikjohnston added S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. O-Occasional Affects or can be seen by some users regularly or most users rarely and removed z-bug (Deprecated Label) z-p2 (Deprecated Label) labels Nov 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Spec-Compliance places where synapse does not conform to the spec O-Occasional Affects or can be seen by some users regularly or most users rarely S-Minor Blocks non-critical functionality, workarounds exist. T-Defect Bugs, crashes, hangs, security vulnerabilities, or other reported issues. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements.
Projects
None yet
Development

No branches or pull requests

5 participants