-
Notifications
You must be signed in to change notification settings - Fork 276
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
Conversation
fc77217
to
b0918eb
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4700 +/- ##
=======================================
Coverage 86.08% 86.08%
=======================================
Files 290 290
Lines 34038 34072 +34
=======================================
+ Hits 29300 29332 +32
- Misses 4738 4740 +2 ☔ View full report in Codecov by Sentry. |
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.
e464490
to
49b2244
Compare
… 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.
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
49b2244
to
0d8ed73
Compare
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.