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

MXC sanitising spec is unclear/impossible to apply #1992

Open
richvdh opened this issue Nov 11, 2024 · 3 comments
Open

MXC sanitising spec is unclear/impossible to apply #1992

richvdh opened this issue Nov 11, 2024 · 3 comments
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit

Comments

@richvdh
Copy link
Member

richvdh commented Nov 11, 2024

https://spec.matrix.org/v1.12/client-server-api/#security-considerations-5 says:

As such, homeservers MUST sanitise mxc:// URIs by allowing only alphanumeric (A-Za-z0-9), _ and - characters in the server-name and media-id values.

... but it's unclear about where this sanitisation should happen. Should it apply to event bodies? If so, which fields in event bodies? Does it matter what the event type is? What about event types we haven't invented yet? What should happen if we see an event that doesn't match?

In practice, it's pretty much impossible to apply such rules to event bodies (particularly for encrypted events), so I don't think that's what it means. But then, what does it mean?

@richvdh richvdh added the clarification An area where the expected behaviour is understood, but the spec could do with being more explicit label Nov 11, 2024
@richvdh
Copy link
Member Author

richvdh commented Nov 11, 2024

This text was added in matrix-org/matrix-spec-proposals#103, ftr

@richvdh
Copy link
Member Author

richvdh commented Nov 11, 2024

(Apparently Synapse doesn't implement any sanitising anyway: element-hq/synapse#1323)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification An area where the expected behaviour is understood, but the spec could do with being more explicit
Projects
None yet
Development

No branches or pull requests

2 participants
@richvdh and others