events with rejected_auth_events must be rejected #1137
Conversation
This might be kinda obvious, but didn't seem to be spelt out anywhere.
| 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. |
There was a problem hiding this comment.
is this really a check on the auth_events or is it a check on the event being inspected?
There was a problem hiding this comment.
multiplied by however many times it shows up in this PR
There was a problem hiding this comment.
I don't understand the question. It's a check on the m.room.create event which is referred to in the auth_events of the event being inspected.
There was a problem hiding this comment.
shouldn't the server be using the m.room.create event from the room rather than auth_events though? It feels more understandable to move this point back up a level rather than nest it unmodified into the auth_events checks.
There was a problem hiding this comment.
possibly, but that seems to be a change to its meaning. Currently we have:
- If event does not have a
m.room.createin itsauth_events, reject. - If the create event...
It's not entirely clear which create event it is talking about in 4, but given the context from 3, surely it's the one from the auth_events.
This is all related to #1136.
There was a problem hiding this comment.
hrrrm, actually, looking at the source to Synapse, it does appear to apply the test to the create event in the room state, so I guess that's an argument that we should make that explicit.
There was a problem hiding this comment.
Ok, I've updated this to make it apply to the room state, rather than the auth events.
| 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
…nts must be rejected Other room versions were updated in matrix-org#1137, but not these ones. Signed-off-by: Kévin Commaille <[email protected]>
This might be kinda obvious, but didn't seem to be spelt out anywhere.
Preview: https://pr1137--matrix-spec-previews.netlify.app