-
Notifications
You must be signed in to change notification settings - Fork 357
Store encryption settings #1460
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
| async fn delete_outgoing_secret_requests(&self, request_id: &TransactionId) -> Result<()>; | ||
|
|
||
| /// TODO: docs | ||
| async fn load_encryption_settings( |
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.
One thing I mentioned already, but it is still my main concern with this patch is that this is expanding the CryptoStore trait. I prefer to avoid this if possible, especially since this functionality is not something the matrix-sdk crate will use.
The idea here is that we might want to reuse the existing get/set value methods the crypto stores have. This would also allow people to store other custom things.
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.
Yea that makes sense, I'll rework it as a separate commit so we can compare 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.
The idea here is that we might want to reuse the existing
get/setvalue methods the crypto stores have. This would also allow people to store other custom things.
To be clear, we would still need to expose something like async fn set_value(&self, key: &str, value: &impl Serialize) -> Result<()>; (and getter equivalent) in the CryptoStore trait, at which point the compiler becomes unhappy about the use of generics when trying to make an object from the trait. Is this what you are suggesting?
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.
Yep, the state store already has such an interface, though it puts the responsibility of serializing onto the caller:
| async fn get_custom_value(&self, key: &[u8]) -> Result<Option<Vec<u8>>> { |
Of course the interface of the CryptoStore needs to be exposed on the OlmMachine where you can put the generic impl Serialize argument if you prefer the Rust side to take care of the serialization.
363e744 to
022028f
Compare
|
@poljar I have restructured this PR to only expose generic If a viable approach, I'd still need to extract the raw-string keys into some kind of enum or so to ensure type safety |
| } | ||
|
|
||
| /// TODO: docs | ||
| pub async fn get_encryption_settings( |
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.
Could we either keep those just in the bindings or if you disagree, let's expose the Store struct and let users use those methods directly on the store.
Of course we need to make sure we don't expose something we don't want.
Yup, this seems nicer than extending the |
92a4b9c to
c5ba87a
Compare
|
After some discussions I decided to create a new table for room settings after all. This is because room settings are sufficiently important concept to warrant the expansion of the I have also decided to not change the |
| let settings = self | ||
| .runtime | ||
| .block_on(self.inner.store().get_room_settings(&room_id))? | ||
| .map(|v| v.try_into().unwrap()); |
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.
How can I flatten the possible error from try_into and return as CryptoStoreError?
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.
You could change the error type that the TryFrom implementation uses from a string to a serde_json error, which supports custom error strings and then do something like:
let settings = self
.runtime
.block_on(self.inner.store().get_room_settings(&room_id))?
.map(|v| v.try_into())
.transpose()?;c5ba87a to
cfb48c3
Compare
|
|
||
| fn serialize_value(&self, value: &impl Serialize) -> Result<Vec<u8>> { | ||
| let serialized = | ||
| rmp_serde::to_vec_named(value).map_err(|x| CryptoStoreError::Backend(x.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.
The mapped error should ideally be CryptoStoreError::Serialization, but this is typed to serde_json instead of rmp_serde and I dont think adding another Serialization case is a good approach. Can we make that serialization error more generic?
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.
Yeah, error handling in the stores is messy... I have an idea on how it may be fixable, will post a separate PR.
1a33c75 to
869e0b4
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #1460 +/- ##
==========================================
- Coverage 75.49% 75.44% -0.06%
==========================================
Files 137 137
Lines 14788 14883 +95
==========================================
+ Hits 11164 11228 +64
- Misses 3624 3655 +31
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report in Codecov by Sentry. |
869e0b4 to
f565a3a
Compare
poljar
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.
I think this looks fine, as long as the unwrap is gone and some more methods are made pub(crate)
| let settings = self | ||
| .runtime | ||
| .block_on(self.inner.store().get_room_settings(&room_id))? | ||
| .map(|v| v.try_into().unwrap()); |
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.
You could change the error type that the TryFrom implementation uses from a string to a serde_json error, which supports custom error strings and then do something like:
let settings = self
.runtime
.block_on(self.inner.store().get_room_settings(&room_id))?
.map(|v| v.try_into())
.transpose()?;115b83b to
f3bc1e8
Compare
4b95afe to
39c4126
Compare
|
@poljar this should now be ready for review. the recent uniffi changes caused some conflicts but all should be resolved against main now |
poljar
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.
Alright, I think this looks good. There's a missing newline and a merge conflict, after this is resolved we can merge.
| dictionary RoomSettings { | ||
| EventEncryptionAlgorithm algorithm; | ||
| boolean only_allow_trusted_devices; | ||
| }; |
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.
Missing newline:
| }; | |
| }; | |
73853f0 to
404b95a
Compare
9f01e06 to
d226738
Compare

Resolves #1578
Add encryption settings to the crypto store that are currently still persisted in legacy client database. These include:
This is achieved by a new
RoomSettingsstruct as well as genericget/set_custom_valuefor global flags.Note that the higher-level non-crypto rust-sdk already stores these values as state events, which is now duplicated by the crypto store. This should be fully migrated to the crypto store because these settings are critical for the cryptographic functionality (e.g. no API to reset room encryption) and are used by clients that only integrate crypto-sdk.