-
Notifications
You must be signed in to change notification settings - Fork 270
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
Changes from 10 commits
df59389
911beb7
e93b16c
e065017
dd81a50
eca4aa4
8019bbf
cd245b5
ae39e4f
c9cca55
cfedc24
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,7 @@ use std::{ | |
sync::Arc, | ||
}; | ||
|
||
use js_option::JsOption; | ||
use ruma::{ | ||
api::client::{ | ||
dehydrated_device::{DehydratedDeviceData, DehydratedDeviceV1}, | ||
|
@@ -161,6 +162,8 @@ pub struct StaticAccountData { | |
pub device_id: OwnedDeviceId, | ||
/// The associated identity keys. | ||
pub identity_keys: Arc<IdentityKeys>, | ||
/// Whether the account is for a dehydrated device. | ||
pub dehydrated: bool, | ||
// The creation time of the account in milliseconds since epoch. | ||
creation_local_time: MilliSecondsSinceUnixEpoch, | ||
} | ||
|
@@ -281,13 +284,17 @@ impl StaticAccountData { | |
), | ||
]); | ||
|
||
DeviceKeys::new( | ||
let mut ret = DeviceKeys::new( | ||
(*self.user_id).to_owned(), | ||
(*self.device_id).to_owned(), | ||
Self::ALGORITHMS.iter().map(|a| (**a).clone()).collect(), | ||
keys, | ||
Default::default(), | ||
) | ||
); | ||
if self.dehydrated { | ||
ret.dehydrated = JsOption::Some(true); | ||
} | ||
ret | ||
} | ||
|
||
/// Get the user id of the owner of the account. | ||
|
@@ -352,6 +359,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, | ||
/// The number of uploaded one-time keys we have on the server. | ||
pub uploaded_signed_key_count: u64, | ||
/// The local time creation of this account (milliseconds since epoch), used | ||
|
@@ -399,6 +409,7 @@ impl Account { | |
user_id: user_id.into(), | ||
device_id: device_id.into(), | ||
identity_keys: Arc::new(identity_keys), | ||
dehydrated: false, | ||
creation_local_time: MilliSecondsSinceUnixEpoch::now(), | ||
}, | ||
inner: Box::new(account), | ||
|
@@ -424,6 +435,17 @@ impl Account { | |
Self::new_helper(account, user_id, &device_id) | ||
} | ||
|
||
/// Create a new random Olm Account for a dehydrated device | ||
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 commentThe 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 commentThe 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. |
||
|
||
let mut ret = Self::new_helper(account, user_id, &device_id); | ||
ret.static_data.dehydrated = true; | ||
ret | ||
} | ||
|
||
/// Get the immutable data for this account. | ||
pub fn static_data(&self) -> &StaticAccountData { | ||
&self.static_data | ||
|
@@ -593,6 +615,7 @@ impl Account { | |
device_id: self.device_id().to_owned(), | ||
pickle, | ||
shared: self.shared(), | ||
dehydrated: self.static_data.dehydrated, | ||
uploaded_signed_key_count: self.uploaded_key_count(), | ||
creation_local_time: self.static_data.creation_local_time, | ||
} | ||
|
@@ -646,6 +669,7 @@ impl Account { | |
user_id: (*pickle.user_id).into(), | ||
device_id: (*pickle.device_id).into(), | ||
identity_keys: Arc::new(identity_keys), | ||
dehydrated: pickle.dehydrated, | ||
creation_local_time: pickle.creation_local_time, | ||
}, | ||
inner: Box::new(account), | ||
|
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.