Auth rules don't explicitly prevent m.room.create events from having auth_events.

[DMRobertson]

Originally from #1048.

Link to problem area: https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules

Issue

The auth rules begin:

1. If type is m.room.create:
   1. If it has any previous events, reject.
   2. If the domain of the room_id does not match the domain of the sender, reject.
   3. If content.room_version is present and is not a recognised version, reject.
   4. If content has no creator field, reject.
   5. Otherwise, allow.

This doesn't restrict the auth_events on m.room.create events. The auth events selection intends for there to be no auth_events:

The auth_events field of a PDU identifies the set of events which give the sender permission to send the event. The auth_events for the m.room.create event in a room is empty; for other events, it should be the following subset of the room state: [...]

But that rule isn't explicitly enforced in the suite of checks on incoming PDUs.

On the face of it, fixing this by requiring servers to reject m.room.create events with auth events would require a room version bump, because it changes the authorisation rules. But the m.room.create event is special in that it marks the start of the event DAG. Perhaps that gives us some extra wiggle room.

[turt2live]

ftr, I believe this restriction is described somewhere else in the spec, though not certain. I feel like it's somewhere in the s2s spec?

A question is whether the clarification fix needs a new room version or not.

[uhoreg]

The m.room.create is rejected if it has prev_events, and I think there's sort of an assumption that if there are no prev_events, then that implies that there can't be any auth_events either. But I don't think there's anything explicit. It would be interesting to see what different implementations react to an event that has no prev_events but has auth_events.