From c3adb4f4da9cb7cc8aa8c5bbdbdcb4039df40314 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Fri, 17 Jun 2022 16:55:06 +0100 Subject: [PATCH 1/2] events with rejected_auth_events must be rejected This might be kinda obvious, but didn't seem to be spelt out anywhere. --- .../newsfragments/1137.clarification | 1 + content/rooms/fragments/v1-auth-rules.md | 39 ++++++++++--------- content/rooms/fragments/v3-auth-rules.md | 37 ++++++++++-------- content/rooms/fragments/v8-auth-rules.md | 35 +++++++++-------- content/rooms/v10.md | 35 +++++++++-------- 5 files changed, 80 insertions(+), 67 deletions(-) create mode 100644 changelogs/room_versions/newsfragments/1137.clarification diff --git a/changelogs/room_versions/newsfragments/1137.clarification b/changelogs/room_versions/newsfragments/1137.clarification new file mode 100644 index 000000000..b7c040454 --- /dev/null +++ b/changelogs/room_versions/newsfragments/1137.clarification @@ -0,0 +1 @@ +For room versions 1 through 10, clarify that events with rejected `auth_events` must be rejected. diff --git a/content/rooms/fragments/v1-auth-rules.md b/content/rooms/fragments/v1-auth-rules.md index 3abc1ac24..6fe95a78d 100644 --- a/content/rooms/fragments/v1-auth-rules.md +++ b/content/rooms/fragments/v1-auth-rules.md @@ -26,22 +26,25 @@ The rules are as follows: version, reject. 4. If `content` has no `creator` field, reject. 5. Otherwise, allow. -2. Reject if event has `auth_events` that: - 1. have duplicate entries for a given `type` and `state_key` pair - 2. have entries whose `type` and `state_key` don't match those +2. Considering the event's `auth_events`: + 1. If there are duplicate entries for a given `type` and `state_key` pair, + reject. + 2. If there are entries whose `type` and `state_key` don't match those specified by the [auth events selection](/server-server-api#auth-events-selection) - algorithm described in the server specification. -3. If event does not have a `m.room.create` in its `auth_events`, - reject. -4. If the create event content has the field `m.federate` set to `false` - and the sender domain of the event does not match the sender domain of - the create event, reject. -5. If type is `m.room.aliases`: + algorithm described in the server specification, reject. + 3. If there are entries which were themselves rejected under the [checks + performed on receipt of a + PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject. + 4. If there is no `m.room.create` event among the entries, reject. + 5. If the `m.room.create` event content has the field `m.federate` set to `false` + and the `sender` domain of the event does not match the `sender` domain of + the create event, reject. +3. If type is `m.room.aliases`: 1. If event has no `state_key`, reject. 2. If sender's domain doesn't matches `state_key`, reject. 3. Otherwise, allow. -6. If type is `m.room.member`: +4. If type is `m.room.member`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `membership` is `join`: 1. If the only previous event is an `m.room.create` and the @@ -98,15 +101,15 @@ The rules are as follows: than the `sender`'s power level, allow. 3. Otherwise, reject. 6. Otherwise, the membership is unknown. Reject. -7. If the `sender`'s current membership state is not `join`, reject. -8. If type is `m.room.third_party_invite`: +5. If the `sender`'s current membership state is not `join`, reject. +6. If type is `m.room.third_party_invite`: 1. Allow if and only if `sender`'s current power level is greater than or equal to the *invite level*. -9. If the event type's *required power level* is greater than the +7. If the event type's *required power level* is greater than the `sender`'s power level, reject. -10. If the event has a `state_key` that starts with an `@` and does not +8. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. -11. If type is `m.room.power_levels`: +9. If type is `m.room.power_levels`: 1. If `users` key in `content` is not a dictionary with keys that are valid user IDs with values that are integers (or a string that is an integer), reject. @@ -130,14 +133,14 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -12. If type is `m.room.redaction`: +10. If type is `m.room.redaction`: 1. If the `sender`'s power level is greater than or equal to the *redact level*, allow. 2. If the domain of the `event_id` of the event being redacted is the same as the domain of the `event_id` of the `m.room.redaction`, allow. 3. Otherwise, reject. -13. Otherwise, allow. +11. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md index 4c238fa29..53340cfe6 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -33,22 +33,25 @@ The complete list of rules, as of room version 3, is as follows: version, reject. 4. If `content` has no `creator` field, reject. 5. Otherwise, allow. -2. Reject if event has `auth_events` that: - 1. have duplicate entries for a given `type` and `state_key` pair - 2. have entries whose `type` and `state_key` don't match those +2. Considering the event's `auth_events`: + 1. If there are duplicate entries for a given `type` and `state_key` pair, + reject. + 2. If there are entries whose `type` and `state_key` don't match those specified by the [auth events selection](/server-server-api#auth-events-selection) - algorithm described in the server specification. -3. If event does not have a `m.room.create` in its `auth_events`, - reject. -4. If the create event content has the field `m.federate` set to `false` - and the sender domain of the event does not match the sender domain of - the create event, reject. -5. If type is `m.room.aliases`: + algorithm described in the server specification, reject. + 3. If there are entries which were themselves rejected under the [checks + performed on receipt of a + PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject. + 4. If there is no `m.room.create` event among the entries, reject. + 5. If the `m.room.create` event content has the field `m.federate` set to `false` + and the `sender` domain of the event does not match the `sender` domain of + the create event, reject. +3. If type is `m.room.aliases`: 1. If event has no `state_key`, reject. 2. If sender's domain doesn't matches `state_key`, reject. 3. Otherwise, allow. -6. If type is `m.room.member`: +4. If type is `m.room.member`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `membership` is `join`: 1. If the only previous event is an `m.room.create` and the @@ -105,15 +108,15 @@ The complete list of rules, as of room version 3, is as follows: than the `sender`'s power level, allow. 3. Otherwise, reject. 6. Otherwise, the membership is unknown. Reject. -7. If the `sender`'s current membership state is not `join`, reject. -8. If type is `m.room.third_party_invite`: +5. If the `sender`'s current membership state is not `join`, reject. +6. If type is `m.room.third_party_invite`: 1. Allow if and only if `sender`'s current power level is greater than or equal to the *invite level*. -9. If the event type's *required power level* is greater than the +7. If the event type's *required power level* is greater than the `sender`'s power level, reject. -10. If the event has a `state_key` that starts with an `@` and does not +8. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. -11. If type is `m.room.power_levels`: +9. If type is `m.room.power_levels`: 1. If `users` key in `content` is not a dictionary with keys that are valid user IDs with values that are integers (or a string that is an integer), reject. @@ -137,7 +140,7 @@ The complete list of rules, as of room version 3, is as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -12. Otherwise, allow. +10. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index 33813a860..e23d7d3a4 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -34,18 +34,21 @@ The rules are as follows: version, reject. 4. If `content` has no `creator` field, reject. 5. Otherwise, allow. -2. Reject if event has `auth_events` that: - 1. have duplicate entries for a given `type` and `state_key` pair - 2. have entries whose `type` and `state_key` don't match those +2. Considering the event's `auth_events`: + 1. If there are duplicate entries for a given `type` and `state_key` pair, + reject. + 2. If there are entries whose `type` and `state_key` don't match those specified by the [auth events selection](/server-server-api#auth-events-selection) - algorithm described in the server specification. -3. If event does not have a `m.room.create` in its `auth_events`, - reject. -4. If the create event content has the field `m.federate` set to `false` - and the sender domain of the event does not match the sender domain of - the create event, reject. -5. If type is `m.room.member`: + algorithm described in the server specification, reject. + 3. If there are entries which were themselves rejected under the [checks + performed on receipt of a + PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject. + 4. If there is no `m.room.create` event among the entries, reject. + 5. If the `m.room.create` event content has the field `m.federate` set to `false` + and the `sender` domain of the event does not match the `sender` domain of + the create event, reject. +3. If type is `m.room.member`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `content` has a `join_authorised_via_users_server` key: @@ -119,15 +122,15 @@ The rules are as follows: or `join`, allow. 4. Otherwise, reject. 8. Otherwise, the membership is unknown. Reject. -6. If the `sender`'s current membership state is not `join`, reject. -7. If type is `m.room.third_party_invite`: +4. If the `sender`'s current membership state is not `join`, reject. +5. If type is `m.room.third_party_invite`: 1. Allow if and only if `sender`'s current power level is greater than or equal to the *invite level*. -8. If the event type's *required power level* is greater than the +6. If the event type's *required power level* is greater than the `sender`'s power level, reject. -9. If the event has a `state_key` that starts with an `@` and does not +7. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. -10. If type is `m.room.power_levels`: +8. If type is `m.room.power_levels`: 1. If `users` key in `content` is not a dictionary with keys that are valid user IDs with values that are integers (or a string that is an integer), reject. @@ -151,7 +154,7 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -11. Otherwise, allow. +9. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/v10.md b/content/rooms/v10.md index 86ef7dc4f..0a8049f8e 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -106,18 +106,21 @@ The rules are as follows: version, reject. 4. If `content` has no `creator` field, reject. 5. Otherwise, allow. -2. Reject if event has `auth_events` that: - 1. have duplicate entries for a given `type` and `state_key` pair - 2. have entries whose `type` and `state_key` don't match those +2. Considering the event's `auth_events`: + 1. If there are duplicate entries for a given `type` and `state_key` pair, + reject. + 2. If there are entries whose `type` and `state_key` don't match those specified by the [auth events selection](/server-server-api#auth-events-selection) - algorithm described in the server specification. -3. If event does not have a `m.room.create` in its `auth_events`, - reject. -4. If the create event content has the field `m.federate` set to `false` - and the sender domain of the event does not match the sender domain of - the create event, reject. -5. If type is `m.room.member`: + algorithm described in the server specification, reject. + 3. If there are entries which were themselves rejected under the [checks + performed on receipt of a + PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject. + 4. If there is no `m.room.create` event among the entries, reject. + 5. If the `m.room.create` event content has the field `m.federate` set to `false` + and the `sender` domain of the event does not match the `sender` domain of + the create event, reject. +3. If type is `m.room.member`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `content` has a `join_authorised_via_users_server` key: @@ -194,15 +197,15 @@ The rules are as follows: or `join`, allow. 4. Otherwise, reject. 8. Otherwise, the membership is unknown. Reject. -6. If the `sender`'s current membership state is not `join`, reject. -7. If type is `m.room.third_party_invite`: +4. If the `sender`'s current membership state is not `join`, reject. +5. If type is `m.room.third_party_invite`: 1. Allow if and only if `sender`'s current power level is greater than or equal to the *invite level*. -8. If the event type's *required power level* is greater than the +6. If the event type's *required power level* is greater than the `sender`'s power level, reject. -9. If the event has a `state_key` that starts with an `@` and does not +7. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. -10. If type is `m.room.power_levels`: +8. If type is `m.room.power_levels`: 1. {{< added-in this="true" >}} If any of the keys `users_default`, `events_default`, `state_default`, `ban`, `redact`, `kick`, or `invite` in `content` are present and @@ -233,7 +236,7 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -11. Otherwise, allow. +9. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: From 97d373c4ec31d1bddf3df5b4b18841c112aa2055 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Mon, 4 Jul 2022 16:25:16 +0100 Subject: [PATCH 2/2] Apply `m.federate` check to the create event in the room state --- content/rooms/fragments/v1-auth-rules.md | 24 ++++++++++++------------ content/rooms/fragments/v3-auth-rules.md | 22 +++++++++++----------- content/rooms/fragments/v8-auth-rules.md | 20 ++++++++++---------- content/rooms/v10.md | 20 ++++++++++---------- 4 files changed, 43 insertions(+), 43 deletions(-) diff --git a/content/rooms/fragments/v1-auth-rules.md b/content/rooms/fragments/v1-auth-rules.md index 6fe95a78d..242c7620c 100644 --- a/content/rooms/fragments/v1-auth-rules.md +++ b/content/rooms/fragments/v1-auth-rules.md @@ -37,14 +37,14 @@ The rules are as follows: performed on receipt of a PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject. 4. If there is no `m.room.create` event among the entries, reject. - 5. If the `m.room.create` event content has the field `m.federate` set to `false` - and the `sender` domain of the event does not match the `sender` domain of - the create event, reject. -3. If type is `m.room.aliases`: +3. If the `content` of the `m.room.create` event in the room state has the + property `m.federate` set to `false`, and the `sender` domain of the event + does not match the `sender` domain of the create event, reject. +4. If type is `m.room.aliases`: 1. If event has no `state_key`, reject. 2. If sender's domain doesn't matches `state_key`, reject. 3. Otherwise, allow. -4. If type is `m.room.member`: +5. If type is `m.room.member`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `membership` is `join`: 1. If the only previous event is an `m.room.create` and the @@ -101,15 +101,15 @@ The rules are as follows: than the `sender`'s power level, allow. 3. Otherwise, reject. 6. Otherwise, the membership is unknown. Reject. -5. If the `sender`'s current membership state is not `join`, reject. -6. If type is `m.room.third_party_invite`: +6. If the `sender`'s current membership state is not `join`, reject. +7. If type is `m.room.third_party_invite`: 1. Allow if and only if `sender`'s current power level is greater than or equal to the *invite level*. -7. If the event type's *required power level* is greater than the +8. If the event type's *required power level* is greater than the `sender`'s power level, reject. -8. If the event has a `state_key` that starts with an `@` and does not +9. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. -9. If type is `m.room.power_levels`: +10. If type is `m.room.power_levels`: 1. If `users` key in `content` is not a dictionary with keys that are valid user IDs with values that are integers (or a string that is an integer), reject. @@ -133,14 +133,14 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -10. If type is `m.room.redaction`: +11. If type is `m.room.redaction`: 1. If the `sender`'s power level is greater than or equal to the *redact level*, allow. 2. If the domain of the `event_id` of the event being redacted is the same as the domain of the `event_id` of the `m.room.redaction`, allow. 3. Otherwise, reject. -11. Otherwise, allow. +12. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/fragments/v3-auth-rules.md b/content/rooms/fragments/v3-auth-rules.md index 53340cfe6..d5da48c54 100644 --- a/content/rooms/fragments/v3-auth-rules.md +++ b/content/rooms/fragments/v3-auth-rules.md @@ -44,14 +44,14 @@ The complete list of rules, as of room version 3, is as follows: performed on receipt of a PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject. 4. If there is no `m.room.create` event among the entries, reject. - 5. If the `m.room.create` event content has the field `m.federate` set to `false` - and the `sender` domain of the event does not match the `sender` domain of - the create event, reject. -3. If type is `m.room.aliases`: +3. If the `content` of the `m.room.create` event in the room state has the + property `m.federate` set to `false`, and the `sender` domain of the event + does not match the `sender` domain of the create event, reject. +4. If type is `m.room.aliases`: 1. If event has no `state_key`, reject. 2. If sender's domain doesn't matches `state_key`, reject. 3. Otherwise, allow. -4. If type is `m.room.member`: +5. If type is `m.room.member`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `membership` is `join`: 1. If the only previous event is an `m.room.create` and the @@ -108,15 +108,15 @@ The complete list of rules, as of room version 3, is as follows: than the `sender`'s power level, allow. 3. Otherwise, reject. 6. Otherwise, the membership is unknown. Reject. -5. If the `sender`'s current membership state is not `join`, reject. -6. If type is `m.room.third_party_invite`: +6. If the `sender`'s current membership state is not `join`, reject. +7. If type is `m.room.third_party_invite`: 1. Allow if and only if `sender`'s current power level is greater than or equal to the *invite level*. -7. If the event type's *required power level* is greater than the +8. If the event type's *required power level* is greater than the `sender`'s power level, reject. -8. If the event has a `state_key` that starts with an `@` and does not +9. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. -9. If type is `m.room.power_levels`: +10. If type is `m.room.power_levels`: 1. If `users` key in `content` is not a dictionary with keys that are valid user IDs with values that are integers (or a string that is an integer), reject. @@ -140,7 +140,7 @@ The complete list of rules, as of room version 3, is as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -10. Otherwise, allow. +11. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/fragments/v8-auth-rules.md b/content/rooms/fragments/v8-auth-rules.md index e23d7d3a4..ac0678847 100644 --- a/content/rooms/fragments/v8-auth-rules.md +++ b/content/rooms/fragments/v8-auth-rules.md @@ -45,10 +45,10 @@ The rules are as follows: performed on receipt of a PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject. 4. If there is no `m.room.create` event among the entries, reject. - 5. If the `m.room.create` event content has the field `m.federate` set to `false` - and the `sender` domain of the event does not match the `sender` domain of - the create event, reject. -3. If type is `m.room.member`: +3. If the `content` of the `m.room.create` event in the room state has the + property `m.federate` set to `false`, and the `sender` domain of the event + does not match the `sender` domain of the create event, reject. +4. If type is `m.room.member`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `content` has a `join_authorised_via_users_server` key: @@ -122,15 +122,15 @@ The rules are as follows: or `join`, allow. 4. Otherwise, reject. 8. Otherwise, the membership is unknown. Reject. -4. If the `sender`'s current membership state is not `join`, reject. -5. If type is `m.room.third_party_invite`: +5. If the `sender`'s current membership state is not `join`, reject. +6. If type is `m.room.third_party_invite`: 1. Allow if and only if `sender`'s current power level is greater than or equal to the *invite level*. -6. If the event type's *required power level* is greater than the +7. If the event type's *required power level* is greater than the `sender`'s power level, reject. -7. If the event has a `state_key` that starts with an `@` and does not +8. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. -8. If type is `m.room.power_levels`: +9. If type is `m.room.power_levels`: 1. If `users` key in `content` is not a dictionary with keys that are valid user IDs with values that are integers (or a string that is an integer), reject. @@ -154,7 +154,7 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -9. Otherwise, allow. +10. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: diff --git a/content/rooms/v10.md b/content/rooms/v10.md index 0a8049f8e..b4c206534 100644 --- a/content/rooms/v10.md +++ b/content/rooms/v10.md @@ -117,10 +117,10 @@ The rules are as follows: performed on receipt of a PDU](server-server-api/#checks-performed-on-receipt-of-a-pdu), reject. 4. If there is no `m.room.create` event among the entries, reject. - 5. If the `m.room.create` event content has the field `m.federate` set to `false` - and the `sender` domain of the event does not match the `sender` domain of - the create event, reject. -3. If type is `m.room.member`: +3. If the `content` of the `m.room.create` event in the room state has the + property `m.federate` set to `false`, and the `sender` domain of the event + does not match the `sender` domain of the create event, reject. +4. If type is `m.room.member`: 1. If no `state_key` key or `membership` key in `content`, reject. 2. If `content` has a `join_authorised_via_users_server` key: @@ -197,15 +197,15 @@ The rules are as follows: or `join`, allow. 4. Otherwise, reject. 8. Otherwise, the membership is unknown. Reject. -4. If the `sender`'s current membership state is not `join`, reject. -5. If type is `m.room.third_party_invite`: +5. If the `sender`'s current membership state is not `join`, reject. +6. If type is `m.room.third_party_invite`: 1. Allow if and only if `sender`'s current power level is greater than or equal to the *invite level*. -6. If the event type's *required power level* is greater than the +7. If the event type's *required power level* is greater than the `sender`'s power level, reject. -7. If the event has a `state_key` that starts with an `@` and does not +8. If the event has a `state_key` that starts with an `@` and does not match the `sender`, reject. -8. If type is `m.room.power_levels`: +9. If type is `m.room.power_levels`: 1. {{< added-in this="true" >}} If any of the keys `users_default`, `events_default`, `state_default`, `ban`, `redact`, `kick`, or `invite` in `content` are present and @@ -236,7 +236,7 @@ The rules are as follows: 1. If the current value is equal to the `sender`'s current power level, reject. 6. Otherwise, allow. -9. Otherwise, allow. +10. Otherwise, allow. {{% boxes/note %}} Some consequences of these rules: