|
|
|
@ -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
|
|
|
|
|
|
|
|
|
|