-
Notifications
You must be signed in to change notification settings - Fork 24
[PM-27115] Force icon uri checksum verification on user crypto v2 #519
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?
Changes from 7 commits
6e0a9c1
fe2d1b3
d97e0bc
15e947a
b50d5b9
79a2ab5
954936b
178fe43
62419e4
26a8ba2
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 |
|---|---|---|
|
|
@@ -113,6 +113,7 @@ struct KeyStoreInner<Ids: KeyIds> { | |
| symmetric_keys: Box<dyn StoreBackend<Ids::Symmetric>>, | ||
| asymmetric_keys: Box<dyn StoreBackend<Ids::Asymmetric>>, | ||
| signing_keys: Box<dyn StoreBackend<Ids::Signing>>, | ||
| security_state_version: u64, | ||
| } | ||
|
|
||
| /// Create a new key store with the best available implementation for the current platform. | ||
|
|
@@ -123,6 +124,7 @@ impl<Ids: KeyIds> Default for KeyStore<Ids> { | |
| symmetric_keys: create_store(), | ||
| asymmetric_keys: create_store(), | ||
| signing_keys: create_store(), | ||
| security_state_version: 1, | ||
| })), | ||
| } | ||
| } | ||
|
|
@@ -138,6 +140,12 @@ impl<Ids: KeyIds> KeyStore<Ids> { | |
| keys.signing_keys.clear(); | ||
| } | ||
|
|
||
| /// Sets the security state version for this store. | ||
| pub fn set_security_state_version(&self, version: u64) { | ||
| let mut data = self.inner.write().expect("RwLock is poisoned"); | ||
| data.security_state_version = version; | ||
| } | ||
|
|
||
| /// Initiate an encryption/decryption context. This context will have read only access to the | ||
| /// global keys, and will have its own local key stores with read/write access. This | ||
| /// context-local store will be cleared when the context is dropped. | ||
|
|
@@ -170,11 +178,13 @@ impl<Ids: KeyIds> KeyStore<Ids> { | |
| /// - [KeyStoreContext::encapsulate_key_unsigned] | ||
| /// - [KeyStoreContext::derive_shareable_key] | ||
| pub fn context(&'_ self) -> KeyStoreContext<'_, Ids> { | ||
| let data = self.inner.read().expect("RwLock is poisoned"); | ||
| KeyStoreContext { | ||
| global_keys: GlobalKeys::ReadOnly(self.inner.read().expect("RwLock is poisoned")), | ||
|
||
| local_symmetric_keys: create_store(), | ||
| local_asymmetric_keys: create_store(), | ||
| local_signing_keys: create_store(), | ||
| security_state_version: data.security_state_version, | ||
| _phantom: std::marker::PhantomData, | ||
| } | ||
| } | ||
|
|
@@ -200,11 +210,14 @@ impl<Ids: KeyIds> KeyStore<Ids> { | |
| /// you're not holding references to the context across await points, as that would cause the | ||
| /// future to also not be [Send]. | ||
| pub fn context_mut(&'_ self) -> KeyStoreContext<'_, Ids> { | ||
| let inner = self.inner.write().expect("RwLock is poisoned"); | ||
| let security_state_version = inner.security_state_version; | ||
| KeyStoreContext { | ||
| global_keys: GlobalKeys::ReadWrite(self.inner.write().expect("RwLock is poisoned")), | ||
| global_keys: GlobalKeys::ReadWrite(inner), | ||
| local_symmetric_keys: create_store(), | ||
| local_asymmetric_keys: create_store(), | ||
| local_signing_keys: create_store(), | ||
| security_state_version, | ||
| _phantom: std::marker::PhantomData, | ||
| } | ||
| } | ||
|
|
||
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.
Non-blocking question: Would we want to add some rollback protection here in the future? Something like:
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.
Yes! However, I do think this should be considered when sync and at least the crypto state is managed in SDK.