For room versions 6 and 7, clarify that events with rejected auth eve… (#2065)

Other room versions were updated in #1103 and #1137, but not these ones.

Signed-off-by: Kévin Commaille <zecakeh@tedomum.fr>

changelogs/room_versions/newsfragments/2065.clarification

@@ -0,0 +1 @@
+For room versions 6 and 7, clarify in the authorization rules that `m.federate` must be checked and that events with rejected auth events must be rejected, for parity with all the other room versions.

content/rooms/v6.md

@@ -88,14 +88,20 @@ The rules are as follows:
         version, reject.
     4.  If `content` has no `creator` property, reject.
     5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
+2.  Considering the event's `auth_events`:
-    1.  have duplicate entries for a given `type` and `state_key` pair
+    1.  If there are duplicate entries for a given `type` and `state_key` pair,
-    2.  have entries whose `type` and `state_key` don't match those
+        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.
+        algorithm described in the server specification, reject.
-3.  If event does not have a `m.room.create` in its `auth_events`,
+    3.  If there are entries which were themselves rejected under the [checks
-    reject.
+        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.
+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 there is no `state_key` property, or no `membership` property in
         `content`, reject.

content/rooms/v7.md

@@ -74,14 +74,20 @@ The rules are as follows:
         version, reject.
     4.  If `content` has no `creator` property, reject.
     5.  Otherwise, allow.
-2.  Reject if event has `auth_events` that:
+2.  Considering the event's `auth_events`:
-    1.  have duplicate entries for a given `type` and `state_key` pair
+    1.  If there are duplicate entries for a given `type` and `state_key` pair,
-    2.  have entries whose `type` and `state_key` don't match those
+        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.
+        algorithm described in the server specification, reject.
-3.  If event does not have a `m.room.create` in its `auth_events`,
+    3.  If there are entries which were themselves rejected under the [checks
-    reject.
+        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.
+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 there is no `state_key` property, or no `membership` property in
         `content`, reject.