MSC4104: Auth Lock: Soft-failure-be-gone! #4104
Conversation
Gnuxie
changed the title
We need to say explicitly that all `m.auth_lock` events that have been created that match the `auth_event` are considered.
It's allowed because servers will still retain the history and an admin can easily recanonicalise the state so that joining servers can see the relevant history again.
turt2live
added
requires-room-version
| The receiving server must combine the `extremities` from both events | ||
| such that the canonical history becomes C -> B -> A. |
There was a problem hiding this comment.
What if Alice sees Chelsea send B -> A but Bob sees C -> A instead, because Chelsea crafted two extremities from the same event, delivering one to Alice's HS and the other to Bob's HS?
There was a problem hiding this comment.
This is a better example. However, provided Bob receives Alice's m.auth_lock, then Bob would reject any further events sent by Chelsea referencing A or C. Bob could also send their own m.auth_lock referencing Chelsea's prior membership that includes C within extremities. Then Alice will be able to pull in C when Alice gets Bob's m.auth_lock. Alice could then redact C.
Though this presents another problem when Bob is unprivileged and can't send m.auth_lock. The reason why we give bob the capability to send m.auth_lock is because we trust that he will observe and apply Alice's m.auth_lock and not leak more of Chelsea's events to us. And this means he's most likely already a room admin. This is a problem that already exists that soft failure doesn't prevent either element-hq/synapse#9329. It would be nice to find some kind of solution.
There was a problem hiding this comment.
Maybe negotiation of extremities could to considered separately, such that servers with unprivileged users could propose them and room admins could preview them and choose to accept or reject them. That does feel a little bit like over engineering for and entrenching a bad state of affairs though. But at least it's something that would work.
There was a problem hiding this comment.
Also, I should probably clarify somewhere in the proposal that we don't propose eagerly issuing an m.auth_lock with every ban, we simply do not soft fail anymore. If we then see events being authorized that would have normally been candidates for soft failure, the room admin or their tooling would then issue m.auth_lock. In principle, this should reduce the number of instances where element-hq/synapse#9329 occurs.
There was a problem hiding this comment.
negotiation
I'm forgetting that a server can ask for the prev_events, find the diverged extremity provide a preview to an admin and allow them to choose incorporate it, all without manual intervention from another server (other than continuing to participate)
There was a problem hiding this comment.
@dkasak I have rewritten the potential issues section to try cover this concern and all the solutions that I have discovered so far
| We counteract this issue by requiring that servers maintain all | ||
| existing `extremities` and their `prev_events`, regardless of | ||
| whether they are missing from the `extremities` field of | ||
| an `m.auth_lock` event. |
There was a problem hiding this comment.
But what is "existing" at the point of receipt of the m.auth_lock event could differ across different servers participating in the room. Wouldn't this strategy lock them into having diverging views of the room?
There was a problem hiding this comment.
No, because users on those servers can issue their own m.auth_lock events for the same locked_event_id, which would allow them to converge again. Am I understanding this correctly as the same problem described in the second paragraph of https://github.com/matrix-org/matrix-spec-proposals/pull/4104/files#r1494856367 ?
Rendered
Signed-off-by: Gnuxie Gnuxie@protonmail.com