Compare commits

..

4 commits

Author SHA1 Message Date
codedust 1381bd037b
Merge f0affdfa3c into d8be2ad942 2025-09-29 14:52:32 +01:00
Johannes Marbach d8be2ad942
The server-name segment of MXC URIs is sanitised differently from the media-id segment (#2217)
Some checks failed
Spec / 🔎 Validate OpenAPI specifications (push) Has been cancelled
Spec / 🔎 Check Event schema examples (push) Has been cancelled
Spec / 🔎 Check OpenAPI definitions examples (push) Has been cancelled
Spec / 🔎 Check JSON Schemas inline examples (push) Has been cancelled
Spec / ⚙️ Calculate baseURL for later jobs (push) Has been cancelled
Spec / 📢 Run towncrier for changelog (push) Has been cancelled
Spell Check / Spell Check with Typos (push) Has been cancelled
Spec / 🐍 Build OpenAPI definitions (push) Has been cancelled
Spec / 📖 Build the spec (push) Has been cancelled
Spec / 🔎 Validate generated HTML (push) Has been cancelled
Spec / 📖 Build the historical backup spec (push) Has been cancelled
Fixes: #1990

Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
2025-09-26 17:36:34 +03:00
Johannes Marbach 21109b4d5b
Push rule IDs are globally unique within their kind (#2214) 2025-09-26 11:02:36 +01:00
Johannes Marbach d4d31a8894
Don't advertise creator field in description of room creation (#2215) 2025-09-26 10:59:21 +01:00
6 changed files with 18 additions and 12 deletions

View file

@ -0,0 +1 @@
Push rule IDs are globally unique within their kind.

View file

@ -0,0 +1 @@
Don't advertise `creator` field in description of room creation.

View file

@ -0,0 +1 @@
The `server-name` segment of MXC URIs is sanitised differently from the `media-id` segment.

View file

@ -3386,10 +3386,10 @@ Unspecified room types are permitted through the use of
### Creation
The homeserver will create an `m.room.create` event when a room is
created, which serves as the root of the event graph for this room. This
event also has a `creator` key which contains the user ID of the room
creator. It will also generate several other events in order to manage
permissions in this room. This includes:
created, which serves as the root of the event graph for this room. The
event `sender` is the user ID of the room creator. The server will also
generate several other events in order to manage permissions in this room.
This includes:
- `m.room.power_levels` : Sets the power levels of users and required power
levels for various actions within the room such as sending events.

View file

@ -134,9 +134,14 @@ entity isn't in the room.
`mxc://` URIs are vulnerable to directory traversal attacks such as
`mxc://127.0.0.1/../../../some_service/etc/passwd`. This would cause the
target homeserver to try to access and return this file. 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. This set of whitelisted characters allows URL-safe
homeservers MUST sanitise `mxc://` URIs by:
- restricting the `server-name` segment to valid
[server names](/appendices/#server-name)
- allowing only alphanumeric (`A-Za-z0-9`), `_` and `-` characters in
the `media-id` segment
The resulting set of whitelisted characters allows URL-safe
base64 encodings specified in RFC 4648. Applying this character
whitelist is preferable to blacklisting `.` and `/` as there are
techniques around blacklisted characters (percent-encoded characters,

View file

@ -83,7 +83,7 @@ Push Ruleset
: A push ruleset *scopes a set of rules according to some criteria*. For
example, some rules may only be applied for messages from a particular
sender, a particular room, or by default. The push ruleset contains the
entire set of scopes and rules.
entire set of rules.
#### Push Rules
@ -91,10 +91,8 @@ A push rule is a single rule that states under what *conditions* an
event should be passed onto a push gateway and *how* the notification
should be presented. There are different "kinds" of push rules and each
rule has an associated priority. Every push rule MUST have a `kind` and
`rule_id`. The `rule_id` is a unique string within the kind of rule and
its' scope: `rule_ids` do not need to be unique between rules of the
same kind on different devices. Rules may have extra keys depending on
the value of `kind`.
`rule_id`. The `rule_id` is a unique string within the kind of rule.
Rules may have extra keys depending on the value of `kind`.
The different `kind`s of rule, in the order that they are checked, are: