-
Notifications
You must be signed in to change notification settings - Fork 269
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for the shared history flag defined in MSC3061 #4700
base: main
Are you sure you want to change the base?
Conversation
… a helper function
…access in some places In several places, we access almost all the fields of a struct to create an `InboundGroupSession` from a pure data struct. When new fields are added to these data structs, it's easy to overlook updating the `InboundGroupSession` accordingly. By using struct destructuring, we ensure that newly added fields are explicitly considered, making it harder to forget one of the newly added fields.
fc77217
to
b0918eb
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4700 +/- ##
==========================================
+ Coverage 85.90% 85.96% +0.06%
==========================================
Files 292 292
Lines 33907 33940 +33
==========================================
+ Hits 29127 29176 +49
+ Misses 4780 4764 -16 ☔ View full report in Codecov by Sentry. |
This patch adds support for the `shared_history` flag from MSC3061 to the `m.room_key` content, exported room keys, and backed-up room keys. The flag is now persisted in our `InboundGroupSession`. Additionally, when creating a new `InboundGroupSession`, we ensure the `shared_history` flag is set appropriately. MSC3061: matrix-org/matrix-spec-proposals#3061
…elves crate a session
b0918eb
to
c4c6c6b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code LGTM, but I think I'll leave reviewing the crypto behaviour to the crypto team 😅 .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks for all the tests and the refactoring.
let PickledInboundGroupSession { | ||
pickle, | ||
sender_key, | ||
signing_key, | ||
sender_data, | ||
room_id, | ||
imported, | ||
backed_up, | ||
history_visibility, | ||
algorithm, | ||
} = pickle; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
YES.
sender_claimed_keys, | ||
forwarding_curve25519_key_chain: _, | ||
} = key; | ||
|
||
let config = OutboundGroupSession::session_config(&key.algorithm)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
&algorithm
?
/// A backed up version of an `InboundGroupSession` | ||
/// A backed up version of an [`InboundGroupSession`]. | ||
/// | ||
/// This can be used to backup the [`InboundGroupSession`] to the server using |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit
/// This can be used to backup the [`InboundGroupSession`] to the server using | |
/// This can be used to back up the [`InboundGroupSession`] to the server using |
/// Whether this [`InboundGroupSession`] can be shared with newly joined | ||
/// users, allowing access to history, as defined in [MSC3061]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we actually do the share when the user is invited -- they may never join.
/// Whether this [`InboundGroupSession`] can be shared with newly joined | |
/// users, allowing access to history, as defined in [MSC3061]. | |
/// Whether this [`InboundGroupSession`] can be shared with users who are invited to the room | |
/// in the future, allowing access to history, as defined in [MSC3061]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This wording appears in a lot of places in this commit -- it could do with updating in all of them.
@@ -184,6 +191,7 @@ impl InboundGroupSession { | |||
sender_data: SenderData, | |||
encryption_algorithm: EventEncryptionAlgorithm, | |||
history_visibility: Option<HistoryVisibility>, | |||
shared_history: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess if you're getting rid of this constructor soon it's fine, but as a matter of good practice, I'd like to see the new parameter documented.
This is the first PR in many for the "Encrypted history sharing" feature.
This specific PR tackles element-hq/element-meta#2720.
There are a couple of commits preparing the introduction of the
shared_history
flag but the meat of the PR is contained in 97a7705. The latter commits add a bunch of tests ensuring that the flag is correctly handled in all the various scenarios where we receive or send a room key.Thus a review commit by commit is advised.
One final note, the main constructor for
InboundGroupSession
now has too many arguments, but I'd like to get rid of that constructor or at least make it private. In many (or perhaps all?) cases this constructor is used to create anInboundGroupSession
for testing purposes. I think that theAccount::create_group_session_pair()
method is better suited for this purpose.