-
Notifications
You must be signed in to change notification settings - Fork 268
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 dehydrated flag to device_keys of dehydrated devices #3164
Conversation
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 know this is still a draft, but since the PR is small I took a look. Left some comments.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3164 +/- ##
==========================================
- Coverage 83.67% 83.65% -0.02%
==========================================
Files 236 236
Lines 24398 24415 +17
==========================================
+ Hits 20414 20425 +11
- Misses 3984 3990 +6 ☔ View full report in Codecov by Sentry. |
@@ -352,6 +358,9 @@ pub struct PickledAccount { | |||
pub pickle: AccountPickle, | |||
/// Was the account shared. | |||
pub shared: bool, | |||
/// Whether this is for a dehydrated device | |||
#[serde(default)] | |||
pub dehydrated: 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.
adding this flag here will break things that create PickledAccount, such as https://github.com/matrix-org/matrix-rust-sdk-crypto-wasm/blob/main/src/libolm_migration.rs#L136 I'm not sure if there's a good way to deal with this.
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.
They'll need to update the bindings just like you did with the matrix-sdk-crypto-ffi
bindings.
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.
OK, I just wasn't sure if there was a better way to do it. I assume this means that the version will need to be bumped since this is a breaking change. Is there a way to flag this so that when the next release gets made, the version will be bumped correctly?
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're still in the 0.X.Y
range of releases, so the correct version will get bumped by design. Adding this as a breaking change to the changelog might make sense to notify people about it.
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.
Left some small nits, looks generally good.
@@ -352,6 +358,9 @@ pub struct PickledAccount { | |||
pub pickle: AccountPickle, | |||
/// Was the account shared. | |||
pub shared: bool, | |||
/// Whether this is for a dehydrated device | |||
#[serde(default)] | |||
pub dehydrated: 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.
They'll need to update the bindings just like you did with the matrix-sdk-crypto-ffi
bindings.
@@ -477,6 +477,10 @@ mod tests { | |||
!request.fallback_keys.is_empty(), | |||
"The dehydrated device creation request should contain some fallback keys" | |||
); | |||
|
|||
let device_keys: crate::types::DeviceKeys = |
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.
Doesn't request.device_keys.deserialize_as()
work here? Also please import DeviceKeys
if you need them.
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.
changed to use deserialize_as
(I didn't know about the function). mod tests
already imports ruma::encryption::DeviceKeys
, so I can't import crate::types::DeviceKeys
at the module-level. Do I just use crate::types::DeviceKeys
at the top of this function? It looks like that's possible, but I've never seen that done, so I don't know if that's a "normal" thing to do.
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.
It's possible, you can also rename things if you import things using use Foo as Bar
.
Co-authored-by: Damir Jelić <poljar@termina.org.uk> Signed-off-by: Hubert Chathi <hubert@uhoreg.ca>
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. Could you get rid of the merge conflict so CI kicks in. After that we can merge.
pub fn new_dehydrated(user_id: &UserId) -> Self { | ||
let account = InnerAccount::new(); | ||
let device_id: OwnedDeviceId = | ||
base64_encode(account.identity_keys().curve25519.as_bytes()).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.
I meant to ask earlier, but on the MSC, I suggested using URL-safe unpadded Base64 instead of plain Base64, since the device ID gets put in path parameters. If you don't have any objections to that, I may as well change this code to make this device ID URL-safe before we merge.
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 were pondering this when we did the iOS implementation and decided against it. The reason being that it would be confusing to have two different representations for a Curve25510 key. One being in the path and one being uploaded as the device keys. Both encodings would end up in the logs as well and confuse potential bug hunters.
Additions: | ||
|
||
- When Olm message decryption fails, report the error code(s) from the failure. | ||
([#3212](https://github.com/matrix-org/matrix-rust-sdk/pull/3212)) | ||
|
||
>>>>>>> main |
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 don't think that this belongs here 😅
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.
Ah, I just noticed one final problem with this. Looks good otherwise.
#[serde(default, skip_serializing_if = "Option::is_none")] | ||
pub dehydrated: Option<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.
Oh wait, this will create an edge case in the signature verification, because we fold the null
case for the dehydrated
property as well as a missing dehydrated
property into the None
case.
You'll have to use this instead: https://docs.rs/js_option/0.1.1/js_option/enum.JsOption.html
Sorry for missing this.
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, just ensure to make CI happy with the formatting.
Code coverage failed due to hitting a limit with codecov.io. But the previous commit was OK, and the last commit was just a formatting change, so should be OK. I don't have permissions in this repo, so someone will need to hit the merge button for me. |
No description provided.