-
Notifications
You must be signed in to change notification settings - Fork 289
crypto: support for building key bundles #4775
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
Conversation
2098247
to
1faf406
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4775 +/- ##
=======================================
Coverage 86.11% 86.12%
=======================================
Files 292 293 +1
Lines 34369 34397 +28
=======================================
+ Hits 29596 29623 +27
- Misses 4773 4774 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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 minus some nits about type names and documentation.
Mainly requesting changes to see what you'll decide to do with the tests.
@@ -1987,6 +1992,36 @@ impl Store { | |||
Ok(futures_util::stream::iter(sessions.into_iter().filter(predicate)) | |||
.then(|session| async move { session.export().await })) | |||
} | |||
|
|||
/// Assemble a room key bundle for sharing encrypted history, as per | |||
/// MSC4268. |
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.
Can we please link to the MSC if we mention it. I have some scripts that find the PR just from MSCXXXX
but other people might not have such advanced technology in their IDE.
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.
yup. Done in 89dee25.
// We sort the sessions in the bundle, so that the snapshot is stable. | ||
bundle.room_keys.sort_by_key(|session| session.session_id.clone()); | ||
insta::with_settings!({ sort_maps => true }, { | ||
assert_json_snapshot!(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.
An alternative to this might be to "redact" or rather replace the random bytes in the snapshot with something stable like I did in c1e28aa:
matrix-rust-sdk/crates/matrix-sdk-crypto/src/olm/group_sessions/inbound.rs
Lines 770 to 775 in 53853c2
assert_json_snapshot!(pickle, { | |
".pickle.initial_ratchet.inner" => "[ratchet]", | |
".pickle.signing_key" => "[signing_key]", | |
".sender_key" => "[sender_key]", | |
".signing_key.ed25519" => "[ed25519_key]", | |
}); |
That would avoid having all the test data here as well as in the snapshot.
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.
Unfortunately, this doesn't work very well here. Because there are several sessions, and we want to check which end up in which section of the output, the redactions get very fiddly. If we wanted to go down that route, it would be simpler to write out the test code by hand.
What does work quite well is a halfway house: we can generate the OlmMachines dynamically whilst still hardcoding the megolm sessions.
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.
Done in 6515b6f.
limitations under the License. | ||
*/ | ||
|
||
//! Types for sharing encrypted room history, per MSC4268 |
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.
Link to the MSC pretty please.
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.
done
pub withheld: Vec<RoomKeyWithheldContent>, | ||
} | ||
|
||
/// An [`InboundGroupSession`] for sharing as part of the key 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.
We should probably describe how this differs from other 4 different room key types we have.
Would be neat to document the dangers of accepting such a room key and that they need to be treated somewhat specially, i.e. they will never be fully trusted like the room keys we receive directly from the creator.
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've added a bunch of documentation which I hope will help, in 27bfeb8
|
||
/// An [`InboundGroupSession`] for sharing as part of the key bundle. | ||
#[derive(Deserialize, Serialize)] | ||
pub struct SharedRoomKey { |
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 find that this name doesn't tell me much, every room key has been shared with you or you're going to share it.
Perhaps we could rename the type and the whole concept as something like a HistoricRoomKey
, which would fit to the planned UI description of "History shared as presented by".
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.
Renamed to HistoricRoomKey
impl Debug for SharedRoomKey { | ||
fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { | ||
f.debug_struct("SharedRoomKey") | ||
.field("algorithm", &self.algorithm) | ||
.field("room_id", &self.room_id) | ||
.field("sender_key", &self.sender_key) | ||
.field("session_id", &self.session_id) | ||
.field("sender_claimed_keys", &self.sender_claimed_keys) | ||
.finish_non_exhaustive() | ||
} | ||
} |
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.
Might make sense to add a snapshot test for this using assert_debug_snapshot!()
.
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.
done in 36f74ed
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.
Thanks for adding so many docs for the different room key types, this is a much needed overview.
/// 3. [`ExportedRoomKey`] is very similar to `ForwardedRoomKeyContent`. The | ||
/// only difference is that the original sender's Ed25519 key is embedded in | ||
/// a `sender_claimed_keys` map rather than a top-level | ||
/// `sender_claimed_ed25519_key` field. |
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 almost forgot about this, now I'm sad again.
Add a method to CryptoStore which will construct a key bundle, ready for encrypting and sharing with invited users. Part of #4504
36f74ed
to
a870c02
Compare
Add a method to CryptoStore which will construct a key bundle, ready for encrypting and sharing with invited users.
Fixes #4504.