Event with invalid auth_events

[timokoesters]

What should happen if an event has at least one invalid auth event?

Synapse currently fails with

Dropping event , which relies on auth_event $qK, which could not be found

But Conduit drops the invalid auth events and tries the auth checks anyway.

Dropping bad events makes Matrix more fault tolerant / easier to repair. For instance, If a member event breaks, one can just leave and rejoin. Currently the rejoin will fail on Synapse because the old broken member event is still in the chain

[erikjohnston]

The problem is that e.g. state res v2 it assumes that all servers has the full copy of the auth chain. So if a server doesn't have the full copy then it may come to different conclusions about the state.

Dropping bad events makes Matrix more fault tolerant / easier to repair. For instance, If a member event breaks, one can just leave and rejoin. Currently the rejoin will fail on Synapse because the old broken member event is still in the chain

What do you mean by break here?

[richvdh]

Is this a subset of https://github.com/matrix-org/matrix-doc/issues/1646? In particular:

We should also define the behaviour when a validation check is not met: should we ignore such events, or reject incoming pushes? For pulls, should we try to get the events from elsewhere?

[timokoesters]

So if a server doesn't have the full copy then it may come to different conclusions about the state

If a server leaves out broken auth_events and the auth checks are all good, then taking more auth events should not make the auth checks suddenly fail.

With "broken" I mean events where the origin server thinks it's alright, but other servers don't accept it at all, usually caused by bugs in server implementations (e.g. event id calculation is wrong, signatures are invalid)

[richvdh]

taking more auth events should not make the auth checks suddenly fail.

this seems to be a bad assumption. It's quite possible to create an event which will pass auth at a subset of its auth events, but not on all of its auth events.

But the debate is academic - as Erik says, the state res algorithm relies on the auth chain to define an partial ordering for events in the room. If some servers don't have all the auth events, they will reach different conclusions about the ordering of events, and hence different conclusions about the state of the room at each point on the DAG.

In short: you should not accept events where some of the auth events are missing/unobtainable/unacceptable. And yes, if an auth event becomes unacceptable due to somebody expiring or changing a signing key, we have a whole lot of problems.

[timokoesters]

@richvdh I understand, leaving out the auth event could leave out an entire branch of the DAG.

Here's a different approach to solve the "If a member event breaks, one can just leave and rejoin" problem. We always leave out the previous member event from the auth_events when doing a leave->* transition.

Does that sound alright? The idea is that a "leave" membership and no membership at all are equivalent, which I think is correct.

[richvdh]

That's fine for event auth, but not for state resolution.

The idea is that a "leave" membership and no membership at all are equivalent,

Unfortunately, they aren't equivalent from the point of view of state resolution, which needs the full chain to know which of two "leave"->"join" transitions came first.

[timokoesters]

Shouldn't state res then fall back to timestamps? It will still be deterministic

[erikjohnston]

Shouldn't state res then fall back to timestamps? It will still be deterministic

Deterministic, yes, but it won't necessarily come to the "right" conclusion. We specifically added leaves as auth events to make it less likely that state would "reset" and cause users to incorrectly be set to "leave" again.

Dropping bad events makes Matrix more fault tolerant / easier to repair. For instance, If a member event breaks, one can just leave and rejoin. Currently the rejoin will fail on Synapse because the old broken member event is still in the chain

It's worth noting that this is basically the only situation where we add a superfluous auth event (i.e. rejoining a public room), so it's quite a niche issue.