-
Notifications
You must be signed in to change notification settings - Fork 358
feat(crypto): Add forwarder_data to InboundGroupSession and pickle.
#5943
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
base: main
Are you sure you want to change the base?
feat(crypto): Add forwarder_data to InboundGroupSession and pickle.
#5943
Conversation
CodSpeed Performance ReportMerging #5943 will not alter performanceComparing Summary
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5943 +/- ##
=======================================
Coverage 88.51% 88.51%
=======================================
Files 363 363
Lines 103432 103466 +34
Branches 103432 103466 +34
=======================================
+ Hits 91548 91581 +33
Misses 7531 7531
- Partials 4353 4354 +1 ☔ View full report in Codecov by Sentry. |
c322d5d to
ceb0c71
Compare
ceb0c71 to
a61c06d
Compare
Issue: #5109 Signed-off-by: Skye Elliot <[email protected]>
a61c06d to
f7c6e5f
Compare
richvdh
left a comment
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.
A few comments and thoughts.
There doesn't seem to be much in the way of tests that forwarder_data gets set correctly. I know that integration tests are coming later, but can we update test_receive_room_key_bundle?
| /// * `sender_data` - If the sessions were received as part of an MSC4268 | ||
| /// key bundle, the information about the user who sent us the bundle. |
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 appears to be referring to a non-existent argument
| if matches!( | ||
| &sender_data, | ||
| // The sender's device must be either `SenderData::SenderUnverified` (i.e., | ||
| // TOFU-trusted) or `SenderData::SenderVerified` (i.e., fully verified | ||
| // via user verification and cross-signing). | ||
| let sender_data = match sender_data { | ||
| SenderData::UnknownDevice { .. } | ||
| | SenderData::VerificationViolation(_) | ||
| | SenderData::DeviceInfo { .. } | ||
| ) { | ||
| warn!( | ||
| "Not accepting a historic room key bundle due to insufficient trust in the sender" | ||
| ); | ||
| return Ok(()); | ||
| } | ||
| | SenderData::VerificationViolation(_) | ||
| | SenderData::DeviceInfo { .. } => { | ||
| warn!( | ||
| "Not accepting a historic room key bundle due to insufficient trust in the sender" | ||
| ); | ||
| return Ok(()); | ||
| } | ||
| SenderData::SenderUnverified(_) | SenderData::SenderVerified(_) => sender_data, | ||
| }; |
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.
now that we pass the whole SenderData into import_room_key_bundle_sessions, I don't think the match statement is an improvement over the old matches! macro. Maybe keep the comment though.
| /// * `sender_data` - If the sessions were received as part of an MSC4268 | ||
| /// key bundle, the information about the user who sent us the bundle. |
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.
another non-existent argument
| /// store. | ||
| pub received_room_key_bundles: Vec<StoredRoomKeyBundleData>, | ||
|
|
||
| pub sender_data: BTreeMap<OwnedRoomId, BTreeMap<String, KnownSenderData>>, |
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 needs documentation at the very least, but I don't understand why it is needed and how it relates to inbound_group_sessions
| &self, | ||
| room_keys: Vec<T>, | ||
| from_backup_version: Option<&str>, | ||
| sender_data: Option<&SenderData>, |
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.
given that this ends up as the forwarder_data rather than the sender_data, it should probably be named accordingly ... and that change could do with chasing up the call stack.
| &self, | ||
| keys: Vec<ExportedRoomKey>, | ||
| from_backup_version: Option<&str>, | ||
| sender_data: Option<&SenderData>, |
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.
since this is unused (and afaik we have no intention to use it), I'd suggest getting rid of it.
| &self, | ||
| exported_keys: Vec<ExportedRoomKey>, | ||
| from_backup_version: Option<&str>, | ||
| sender_data: Option<&SenderData>, |
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.
needs doc.
| let mut keys = BTreeMap::new(); | ||
|
|
||
| for (i, key) in room_keys.into_iter().enumerate() { | ||
| match key.try_into() { |
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.
Low-confidence comment:
It feels like, ideally, we ought to be setting the InboundGroupSession::forwarder_data at the point we convert from HistoricRoomKey: it's not really meaningful to convert from HistoricRoomKey to InboundGroupSession without a forwarder_data.
In other words, we should replace InboundGroupSession::try_from(&HistoricRoomKey) with some other method that also takes a &SenderData.
On the flip side, import_sessions_impl is used for ExportedRoomKey as well as HistoricRoomKey, so this change would probably mean pushing the try_into call, and hence the error handling up the stack. It might give us more code and less clarity.
WDYT?
Issue: #5109