Compare commits

..

No commits in common. "1415b6b1baef1b6772ab1811ebe204a0e8dab2b5" and "96438321bd8e4d2782337d0d15e440acef1b49e1" have entirely different histories.

View file

@ -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 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` `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 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 an indication to users that their encrypted messages Clients SHOULD show a visual indication to users that their encrypted messages
may be shared with future room members in this way. may be shared with future room members in this way.
Recipients SHOULD keep a record of the `shared_history` flag for each Recipients SHOULD keep a record of the `shared_history` flag for each
@ -1610,35 +1610,35 @@ room.
##### Construction and sharing of the key bundle ##### Construction and sharing of the key bundle
Alice's client MAY choose not to share any room history (even messages sent when the Alice MAY choose not to share any room history (even messages sent when the
history visibity setting would allow sharing) if the current history history visibity setting would allow sharing) if the current history
visibility setting does not allow sharing (i.e. if `history_visibility` is visibility setting does not allow sharing (i.e. if `history_visibility` is
set to `invited` or `joined`). set to `invited` or `joined`).
Otherwise, before inviting Bob to a room, Alice's client constructs and sends a key bundle as follows: Otherwise, before inviting Bob to a room, Alice constructs and sends a key bundle as follows:
1. Alice's client SHOULD ensure that it has downloaded all keys relevant to the room 1. Alice SHOULD ensure that she has downloaded all keys relevant to the room
from [server-side key backup](#server-side-key-backups), if she is using it. from [server-side key backup](#server-side-key-backups), if she is using it.
2. Alice's client constructs a [`RoomKeyBundle`](#definition-roomkeybundle) structure, 2. Alice constructs a [`RoomKeyBundle`](#definition-roomkeybundle) structure,
containing the sessions she is aware of in the room. Alice MUST include containing the sessions she is aware of in the room. Alice SHOULD include
only [shareable encryption sessions](#shareable-encryption-sessions) in the only [shareable encryption sessions](#shareable-encryption-sessions) in the
`room_keys` section of the structure; other sessions SHOULD be listed in the `room_keys` section of the structure; other sessions should be listed un the
with `withheld` section. with `withheld` section.
3. The client serialises the `RoomKeyBundle` as JSON. 3. Alice serialises the `RoomKeyBundle` as JSON.
4. Alice's client encrypts and uploads the serialised JSON in the same way as when 4. Alice encrypts and uploads the serialised JSON in the same way as when
[sending an encrypted attachment](#sending-encrypted-attachments). [sending an encrypted attachment](#sending-encrypted-attachments).
5. Alice's client ensures she has an up-to-date list of Bob's devices (performing a 5. Alice ensures she has an up-to-date list of Bob's devices (performing a
[`/keys/query`](#post_matrixclientv3keysquery) request if necessary). [`/keys/query`](#post_matrixclientv3keysquery) request if necessary).
6. For each of Bob's devices which are correctly 6. For each of Bob's devices which are correctly
[cross-signed](#cross-signing), Alice's client encrypts and sends an [cross-signed](#cross-signing), Alice encrypts and sends an
[`m.room_key_bundle`](#mroom_key_bundle) message. [`m.room_key_bundle`](#mroom_key_bundle) message.
Alice's client MUST NOT send the `m.room.key_bundle` message to devices that have not Alice 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 been correctly cross-signed by their owner, due to the risk of sharing
significant amounts of encrypted content with an attacker-controlled device. 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: 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 * 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 it. Note, however, that this process must be resilient to Bob's client being
restarted before the download/import completes. 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 of attempting to download a key bundle on every startup. 24 hours is a
recommended time limit.) 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 download it immediately. If he later accepts an invite to the room from
Alice, his client downloads and processes the bundle at that point. Alice, his client downloads and processes the bundle at that point.
@ -2008,10 +2008,6 @@ following happens:
treat any membership event with a membership other than `join` as an treat any membership event with a membership other than `join` as an
indication that the affected user may have joined and left the room. 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 #### Protocol definitions
##### Events ##### Events