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.

Sign up for GitHub

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

events with rejected_auth_events must be rejected #1137

Merged
merged 2 commits into from
Jul 5, 2022
Merged

events with rejected_auth_events must be rejected #1137

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c3adb4f
events with rejected_auth_events must be rejected
richvdh Jun 17, 2022
97d373c
Apply `m.federate` check to the create event in the room state
richvdh Jul 4, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelogs/room_versions/newsfragments/1137.clarification
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
For room versions 1 through 10, clarify that events with rejected `auth_events` must be rejected.
39 changes: 21 additions & 18 deletions content/rooms/fragments/v1-auth-rules.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
3. If the `content` of the `m.room.create` event in the room state has the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we might want to clarify which room state (at or before the event in question?), though hopefully for the create event it doesn't matter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

applies to other snippets too

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, it's the same state that all the other auth rules refer to. Per https://spec.matrix.org/v1.3/server-server-api/#checks-performed-on-receipt-of-a-pdu, we actually check them at three different states.

I agree all this could be clarified, but I don't think it's the job of this PR.

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.
6. 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
Expand Down Expand Up @@ -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`:
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*.
9. 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.
10. 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.
11. 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.
Expand All @@ -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`:
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.
13. Otherwise, allow.
12. Otherwise, allow.

{{% boxes/note %}}
Some consequences of these rules:
Expand Down
37 changes: 20 additions & 17 deletions content/rooms/fragments/v3-auth-rules.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
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.
6. 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
Expand Down Expand Up @@ -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`:
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*.
9. 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.
10. 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.
11. 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.
Expand All @@ -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.
11. Otherwise, allow.

{{% boxes/note %}}
Some consequences of these rules:
Expand Down
35 changes: 19 additions & 16 deletions content/rooms/fragments/v8-auth-rules.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
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:
Expand Down Expand Up @@ -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`:
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*.
8. 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.
9. 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.
10. 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.
Expand All @@ -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.
10. Otherwise, allow.

{{% boxes/note %}}
Some consequences of these rules:
Expand Down
35 changes: 19 additions & 16 deletions content/rooms/v10.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
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:
Expand Down Expand Up @@ -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`:
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*.
8. 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.
9. 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.
10. 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
Expand Down Expand Up @@ -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.
10. Otherwise, allow.

{{% boxes/note %}}
Some consequences of these rules:
Expand Down