mirror of
https://github.com/matrix-org/matrix-spec
synced 2026-08-04 15:07:47 +02:00
Compare commits
3 commits
96438321bd
...
1415b6b1ba
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
1415b6b1ba | ||
|
|
c38246251e | ||
|
|
a7f1d772c6 |
|
|
@ -1573,9 +1573,9 @@ keys to Bob via an [`m.room_key`](#mroom_key) message, she sets
|
|||
If the history visibility changes in a way that would affect the
|
||||
`shared_history` flag (i.e., it changes from `joined` or `invited` to `shared`
|
||||
or `world_readable`, or vice versa), then clients MUST rotate their outbound
|
||||
megolm session before sending more messages.
|
||||
Megolm session before sending more messages.
|
||||
|
||||
Clients SHOULD show a visual indication to users that their encrypted messages
|
||||
Clients SHOULD show an indication to users that their encrypted messages
|
||||
may be shared with future room members in this way.
|
||||
|
||||
Recipients SHOULD keep a record of the `shared_history` flag for each
|
||||
|
|
@ -1610,35 +1610,35 @@ room.
|
|||
|
||||
##### Construction and sharing of the key bundle
|
||||
|
||||
Alice MAY choose not to share any room history (even messages sent when the
|
||||
Alice's client MAY choose not to share any room history (even messages sent when the
|
||||
history visibity setting would allow sharing) if the current history
|
||||
visibility setting does not allow sharing (i.e. if `history_visibility` is
|
||||
set to `invited` or `joined`).
|
||||
|
||||
Otherwise, before inviting Bob to a room, Alice constructs and sends a key bundle as follows:
|
||||
Otherwise, before inviting Bob to a room, Alice's client constructs and sends a key bundle as follows:
|
||||
|
||||
1. Alice SHOULD ensure that she has downloaded all keys relevant to the room
|
||||
1. Alice's client SHOULD ensure that it has downloaded all keys relevant to the room
|
||||
from [server-side key backup](#server-side-key-backups), if she is using it.
|
||||
|
||||
2. Alice constructs a [`RoomKeyBundle`](#definition-roomkeybundle) structure,
|
||||
containing the sessions she is aware of in the room. Alice SHOULD include
|
||||
2. Alice's client constructs a [`RoomKeyBundle`](#definition-roomkeybundle) structure,
|
||||
containing the sessions she is aware of in the room. Alice MUST include
|
||||
only [shareable encryption sessions](#shareable-encryption-sessions) in the
|
||||
`room_keys` section of the structure; other sessions should be listed un the
|
||||
`room_keys` section of the structure; other sessions SHOULD be listed in the
|
||||
with `withheld` section.
|
||||
|
||||
3. Alice serialises the `RoomKeyBundle` as JSON.
|
||||
3. The client serialises the `RoomKeyBundle` as JSON.
|
||||
|
||||
4. Alice encrypts and uploads the serialised JSON in the same way as when
|
||||
4. Alice's client encrypts and uploads the serialised JSON in the same way as when
|
||||
[sending an encrypted attachment](#sending-encrypted-attachments).
|
||||
|
||||
5. Alice ensures she has an up-to-date list of Bob's devices (performing a
|
||||
5. Alice's client ensures she has an up-to-date list of Bob's devices (performing a
|
||||
[`/keys/query`](#post_matrixclientv3keysquery) request if necessary).
|
||||
|
||||
6. For each of Bob's devices which are correctly
|
||||
[cross-signed](#cross-signing), Alice encrypts and sends an
|
||||
[cross-signed](#cross-signing), Alice's client encrypts and sends an
|
||||
[`m.room_key_bundle`](#mroom_key_bundle) message.
|
||||
|
||||
Alice MUST NOT send the `m.room.key_bundle` message to devices that have not
|
||||
Alice's client MUST NOT send the `m.room.key_bundle` message to devices that have not
|
||||
been correctly cross-signed by their owner, due to the risk of sharing
|
||||
significant amounts of encrypted content with an attacker-controlled device.
|
||||
|
||||
|
|
@ -1651,7 +1651,7 @@ significant amounts of encrypted content with an attacker-controlled device.
|
|||
When Bob's client receives an `m.room_key_bundle` event from Alice, there are two possibilities:
|
||||
|
||||
* If Bob has recently accepted an invite to the room from Alice, the client
|
||||
should immediately download and decrypt the key bundle and start processing
|
||||
SHOULD immediately download and decrypt the key bundle and start processing
|
||||
it. Note, however, that this process must be resilient to Bob's client being
|
||||
restarted before the download/import completes.
|
||||
|
||||
|
|
@ -1661,7 +1661,7 @@ When Bob's client receives an `m.room_key_bundle` event from Alice, there are tw
|
|||
of attempting to download a key bundle on every startup. 24 hours is a
|
||||
recommended time limit.)
|
||||
|
||||
* Otherwise, Bob's client should store the details of the key bundle but not
|
||||
* Otherwise, Bob's client SHOULD store the details of the key bundle but not
|
||||
download it immediately. If he later accepts an invite to the room from
|
||||
Alice, his client downloads and processes the bundle at that point.
|
||||
|
||||
|
|
@ -2008,6 +2008,10 @@ following happens:
|
|||
treat any membership event with a membership other than `join` as an
|
||||
indication that the affected user may have joined and left the room.
|
||||
|
||||
* {{% added-in v="1.19" %}} The [history visibility](#room-history-visibility)
|
||||
state of the room changes in a way that would affect the `shared_history`
|
||||
flag: see [shareable encryption sessions](#shareable-encryption-sessions).
|
||||
|
||||
#### Protocol definitions
|
||||
|
||||
##### Events
|
||||
|
|
|
|||
Loading…
Reference in a new issue