-
Notifications
You must be signed in to change notification settings - Fork 359
Create a separate error variant to indicate a failure importing a secret. #5647
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
CodSpeed Performance ReportMerging #5647 will improve performances by 46.97%Comparing Summary
Benchmarks breakdown
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #5647 +/- ##
========================================
Coverage 88.30% 88.30%
========================================
Files 357 357
Lines 98509 98743 +234
Branches 98509 98743 +234
========================================
+ Hits 86987 87196 +209
- Misses 7389 7420 +31
+ Partials 4133 4127 -6 ☔ View full report in Codecov by Sentry. |
|
Not sure why the one unit test is failing. It looks completely unrelated to what I changed, and the test succeeds on my machine. |
Hywan
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.
It looks great to me! Thanks. I've a couple of feedback, but no blocker.
crates/matrix-sdk/src/encryption/secret_storage/secret_store.rs
Outdated
Show resolved
Hide resolved
| if let Some(secret_content) = | ||
| self.client.account().fetch_account_data(event_type).await.map_err(ImportError::from)? |
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.
Should be a fixup of the prefix patch.
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 the commit to be a fixup. Hopefully I did it right.
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.
But the CI is complaining about the fixup, so not sure what's going on. :-/
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.
That's just a reminder for us to squash the fixup commits.
| #[error("Error importing a secret: {error_message}")] | ||
| Import { error_message: String }, |
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.
Sorry for the drive-by comment, but don't we want to remember which secret couldn't have been imported?
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 wasn't needed for the issue I was working on, but it does sound like it could be useful. I guess it means that I can't just use ImportError::from (or I can't just use the automatic conversion from ImportError to SecretStorageError. Is there some sort of convention that I should follow?
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 won't be able to use the automatic conversion, but you can just map_err() from one error to the other and include the context that we can't infer automatically this way.
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.
Sorry, I wasn't clear with my question. I was wondering if there was a convention for what to put in the map_err. Should I just throw an anonymous function in there? Or should I pre-define some functions in ImportError? Or something else?
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.
Depends on how many times you need to do the same map, two or more use a pre-defined function, otherwise anonymous functions are fine.
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 changed SecretStorageError::ImportError to have name and error fields, where name is the name of the secret that was being imported. It all seems fine except that the way SecretStore.import_secrets imports the cross signing keys is that it loads all the secrets from Secret Storage (which is fine, it calls SecretStore.get_secret individually on each secret name), but then it bundles them all up and calls OlmMachine.import_cross_signing_keys on the whole bundle. In there, it will error, for example, if one of the private keys doesn't match the public key.
But that means that I can't tell which secret caused the error, unless I modify the error type returned by OlmMachine.import_cross_signing_keys so that it contains the secret name, which means changing stuff in the crypto crate. I'm a bit hesitant to go deeper into the Rust SDK for this, since it will probably affect more stuff, but I think it's the only way to get the right information. So, just wanted to double check that it's OK for me to do that.
I think the alternative would be to hard-code something in SecretStore.import_secrets saying that it's, say, the Master key that caused the error, and hope for the best, but I'm not too excited about that either.
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 it's fine to include that in the crypto crate as well. Sure that's a breaking change but a fairly minor one.
dc0ff15 to
0cb753f
Compare
Signed-off-by: Hubert Chathi <[email protected]>
6394f2c to
d227f74
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.
Looks good to me.
ee614bc to
c3ea78e
Compare
|
Ping @Hywan: can you give this a re-review? |
Part of the fix to element-hq/element-x-android#5099
Allows applications to distinguish between errors that occur when unlocking Secret Storage, or errors that occur when importing a secret, so that they can display appropriate feedback (or not) to the user.
Signed-off-by: