rejected event used as an auth event

[richvdh]

in my database, $h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 (a regular membership event) uses $NncVOvrPzkKl0u1Q8FIJ7Pz1kZH1iF2lwWj6pZ6+Kkg (a membership event which was rejected due to missing auth events) as an auth event. This seems wrong: $h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 should have been rejected too.

Logs from the arrival of that event:

2021-03-08 16:00:19,930 - synapse.handlers.federation - 189 - INFO - PUT-2238636-$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 - handling received PDU: <FrozenEventV2 event_id='$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4', type='m.room.member', state_key='@yan:yetanothernerd.xyz'>
2021-03-08 16:00:20,090 - synapse.handlers.federation - 2406 - INFO - PUT-2238636-$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 - auth_events refers to events which are not in our calculated auth chain: {'$NncVOvrPzkKl0u1Q8FIJ7Pz1kZH1iF2lwWj6pZ6+Kkg'}
2021-03-08 16:00:20,090 - synapse.state - 452 - INFO - PUT-2238636-$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 - Resolving state for !BAXLHOFjvDKUeLafmO:matrix.org with 2 groups
2021-03-08 16:00:20,091 - synapse.handlers.federation - 2446 - INFO - PUT-2238636-$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 - After state res: updating auth_events with new state {}
2021-03-08 16:00:20,501 - synapse.state - 573 - INFO - PUT-2238636-$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 - Resolving state for !BAXLHOFjvDKUeLafmO:matrix.org with groups [2956930, 2831560, 2969615, 2956433, 2893843]
2021-03-08 16:00:21,115 - synapse.storage.databases.main.event_federation - 230 - INFO - PUT-2238636-$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 - Unexpectedly found that events don't have chain IDs in room !BAXLHOFjvDKUeLafmO:matrix.org: {'$NncVOvrPzkKl0u1Q8FIJ7Pz1kZH1iF2lwWj6pZ6+Kkg'}
2021-03-08 16:01:19,925 - synapse.http.site - 219 - INFO - PUT-2238636 - Connection from client lost before response was sent
2021-03-08 16:03:22,528 - synapse.state.v2 - 531 - WARNING - PUT-2238636-$h+BUjV0LuuSRmFh5ZFeSVZkP+oo6v7bhyJ+1wYjpLb4 - auth_event id $S38_aRG4Qz8eIdrTyzJuQdH3Ieus1Y1dhczoFKnOB7M for event $NncVOvrPzkKl0u1Q8FIJ7Pz1kZH1iF2lwWj6pZ6+Kkg is missing
2021-03-08 16:03:30,846 - synapse.http.server - 636 - WARNING - PUT-2238636 - Not sending response to request <XForwardedForRequest at 0x7fd1acb68860 method='PUT' uri='/_matrix/federation/v1/send/1614863178168' clientproto='HTTP/1.0' site='8008'>, already disconnected.
2021-03-08 16:03:30,846 - synapse.access.http.8008 - 316 - INFO - PUT-2238636 - 2a00:1098:84:1c8::157 - 8008 - {matrix.org} Processed request: 190.923sec/-130.921sec (0.982sec, 0.012sec) (0.080sec/187.732sec/31) 0B 200! "PUT /_matrix/federation/v1/send/1614863178168 HTTP/1.0" "Synapse/1.29.0rc1 (b=matrix-org-hotfixes,61a970e25)" [3 dbevts]

[richvdh]

this room is continuing to cause severe problems on my server. I'm going to leave it to try to make federation work again.

[ShadowJonathan]

(Doing /join on that room, it looks to be the "IRC Matrix Bridges" room, for anyone's reference, #irc:matrix.org)

[richvdh]

The main problem here is that _check_event_auth, and its helper _update_auth_events_and_context_for_auth, make incorrect assumptions about whether the auth events being passed in in claimed_auth_event_map have themselves been authed. Unfortunately it's not quite as simple as just checking that they have been authed, because the whole reason we have claimed_auth_event_map (rather than just pulling the events out of the db) is that they haven't been persisted, either.

Really, we need to get rid of the whole premise of claimed_auth_event_map - we should not be persisting events before their auth_events are persisted. Unfortunately, if we just remove it, auth_events does something completely different wherein it tries to work out what the auth events should be based on the current state of the room.

The two methods are also very confused about whether the auth events they are working with are those according to the auth_events of the event being persisted, or what we think the auth events should be given the state of the room at that point (which obviously only makes sense for non-outliers, not that that stops us trying to do it anyway).

• Clean up confusing functions which modify their inputs (Clean up federation event auth code #10539)
• Stop turning things into outliers unnecessarily (Stop setting the outlier flag for things that aren't #10614)
• Remove the duplication between backfill and get_missing_events (Refactor on_receive_pdu code #10615, Extract _resolve_state_at_missing_prevs #10624, Split on_receive_pdu in half #10640, Make backfill and get_missing_events use the same codepath #10645)
• Figure out which paths are used for outliers, which for full events, and which for both. (Add some assertions about outliers #10773)
• I'm hoping that will show that _check_event_auth is given a claimed_auth_event_map iff event is an outlier - which will then mean we can split it and _update_auth_events_and_context_for_auth in half. (Inline _check_event_auth for outliers #10926)
• Ensure that wherever we set claimed_auth_event_map, the events in question have been persisted first. (Persist auth events before the events that rely on them #10771, Factor out common code for persisting fetched auth events #10896)
• Ensure that event_auth.check checks for rejected events. (Ensure that we reject events which use rejected events for auth #10956)
• For non-outliers, auth the events based on their claimed auth events, as well as our calculated auth events. (Check auth on received events' auth_events #11001)
• Check _persist_auth_tree auths auth_events correctly. _persist_auth_tree is only used when processing the results of a send_join (ie, when joining a new room over federation). It seems to fetch missing auth events over federation, but never actually persists them? (Ensure that we correctly auth events returned by send_join #11012)
• _auth_and_persist_outliers could do with being optimised #11013
• Handle events which fail auth on their auth_events differently from those that fail on the resolved state #11018