From e15517ee53981e94d8e4a4195d11fd50206c4f7c Mon Sep 17 00:00:00 2001 From: gnuxie Date: Mon, 19 Feb 2024 19:21:18 +0000 Subject: [PATCH] Rewrite issues. --- .../4104-auth-lock-soft-failure-be-gone.md | 98 +++++++++++++++---- 1 file changed, 77 insertions(+), 21 deletions(-) diff --git a/proposals/4104-auth-lock-soft-failure-be-gone.md b/proposals/4104-auth-lock-soft-failure-be-gone.md index 9f6eea85..87d9b46e 100644 --- a/proposals/4104-auth-lock-soft-failure-be-gone.md +++ b/proposals/4104-auth-lock-soft-failure-be-gone.md @@ -72,7 +72,7 @@ Considering the event's `auth_events`: ## Potential issues -### Conflicting auth-lock events +### Multiple auth-lock events Imagine that there are two admins in a room, Alice and Bob. Imagine that there is a malicious user Chelsea. @@ -83,46 +83,102 @@ Alice and Bob both issue auth_lock events for Chelsea's prior membership. Alice's `extremities` field includes `B`, but excludes `C`. Bob's `extremities` field includes `C`. +#### Solution + The receiving server must combine the `extremities` from both events such that the canonical history becomes C -> B -> A. +This is already explicitly written within the authorization rules +in this MSC. + +### Diverging `extremities` + +Imagine Bob's server receives an `m.auth_lock` event and Bob's server +has authorized events referencing the `locked_event_id` that are not +present within any relevant `m.auth_lock`'s `extremities`. +Bob's server must decide what to do with the events it has already +authorized. + +This is a problem that occurs in the following scenarios: + +#### Scenario A: Alice deliberately encodes less `extremities` than Bob has +Alice issues an `m.auth_lock` to deliberately encode less or no +extremities, in an attempt permanently to diverge Bob's DAG. +Joining user David would then also not be able to see a large portion +of the history that Bob can, because it wouldn't be authorized in +David's DAG when David backfills. + +#### Scenario B: Alice issues a lock quickly after changing an auth event + +Imagine that Alice issues an `m.room.power_levels` event P. +Alice revises this event so that it becomes P'. +Alice issues an auth_lock for P, Lock-P. +Imagine that Alice receives an event B from Bob that references P. +Alice and every other server with Lock-P is forced to reject event B. + +#### Scenario C: Bob's events are mixed with Chelsea's + +Chelsea has sent `X -> A` to Alice, but `Y -> A` to Bob. +Bob has then appended `B -> Y -> A` and in turn Chelsea +has appended `Z -> B -> Y -> A` and sent `Z` to Bob. -### Issuing `m.auth_lock` to deliberately encode less or no extremities +Alice has banned Chelsea and locked Chelsea's prior membership. +Only now has Bob received this `m.auth_lock` event, and it only +contains the extremity `X`. + +Alice can get `B` if Bob sends it to her, +but new joiner David will probably be unable to by backfilling `B`, +at least if David's server doesn't have special code to account +for the connected events being rejected. #### Effects on participating servers -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. +Servers are required to maintain all their existing `extremities` +and their `prev_events`, regardless of whether they are missing from +the `extremities` field of any `m.auth_lock` event. + +These servers should still incorporate these diverged `extremities` +into `prev_events` so that they can be discovered and repaired later. #### Effects on joining servers Joining servers will no longer be able to authorize large parts of the room's history. -### Split history for unprivileged users on unprivileged servers +#### Solution A: Dedicated API for showing diverged events to room admins -Imagine that Alice issues an `m.room.power_levels` event P. -Alice revises this event so that it becomes P'. -Alice issues an auth_lock for P, Lock-P. -Imagine that Alice receives an event B from Bob that references P. -Alice is forced to reject event B. +A room administrator could be made aware of all the extremities that +are diverged. This can be done because a server can detect when +authorized events contain references to unauthorized events +within `prev_events` of authorized events in the DAG. -#### Resolution +A room administrator can then preview the effects of incorporating +diverged extremities and make a decision to do so via the +`extremities` field of `m.auth_lock`. -Bob receives Lock-P, and notices that B is absent from the chain -specified in Lock-P's `extremities`. +#### Solution B: Room administrators on other servers issue their own `m.auth_lock` + +Room admins residing on different servers with diverged extremities +can issue their own `m.auth_lock` event to include diverged extremities. +When this event is received by other servers, the diverged extremities +can be authorized and the DAG will converge again. + +#### Solution C: Unprivileged users propose changes to the `extremities` of `m.auth_lock` + +Participants in the room can propose changes to the `extremities` +contained within `m.auth_lock` via a dedicated event. Room administrators +can then review the effects and merge them. + +#### Solution D: Recrafting PDUs + +Take scenario B. Bob receives Lock-P, and notices that B is absent +from the chain specified in Lock-P's `extremities`. We would need a new MSC for bob to resend B as B' such that servers who have accepted B would recognise B' to be a duplicate that references more recent authorization events. -### Redaction of `m.auth_lock` - -We probably do want the lock to be redactable. -But how can you be sure that you're not opening Pandora's box by -allowing hidden malicious events residing on participating servers -to suddenly be incorporated into the DAG? +This would allow Alice to see `B` in Scenario C. But it wouldn't +allow Alice to redact `Z` or `Y`, which Bob my find harmful. ### Locking all current auth events