-
-
Notifications
You must be signed in to change notification settings - Fork 592
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 crypto methods for export and import of secrets bundle #4227
Conversation
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
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.
Some minor comments
import type * as RustSdkCryptoJs from "@matrix-org/matrix-sdk-crypto-wasm"; | ||
|
||
declare module "@matrix-org/matrix-sdk-crypto-wasm" { | ||
interface OlmMachine { |
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.
Why do we need this? isn't it already in the index.d.ts of matrix-sdk-crypto-wasm
?
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 but with return types of any
- see matrix-org/matrix-rust-sdk-crypto-wasm#110
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.
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.
This should be fixed on the wasm side; matrix-org/matrix-rust-sdk-crypto-wasm#123 does so but it will need a release cycle :/
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.
Well, that PR doesn't help with the return type of SecretsBundle.to_json
, to be fair. On the other hand: do you actually need to introspect the result of SecretsBundle.to_json
outside of tests (where I would be inclined to do some @ts-ignore
ing rather than have a separate definition to keep in step)?
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.
Well, that PR doesn't help with the return type of SecretsBundle.to_json, to be fair. On the other hand: do you actually need to introspect the result of SecretsBundle.to_json outside of tests (where I would be inclined to do some @ts-ignoreing rather than have a separate definition to keep in step)?
It should still be a useful type otherwise you'll get junk into the import method. If it isn't meant to be introspectable then it should be a branded type so a round-trip export->import works without needing to rely on any
}, | ||
}; | ||
await rustCrypto.importSecretsForQrLogin(bundle); | ||
await expect(rustCrypto.exportSecretsForQrLogin()).resolves.toEqual(expect.objectContaining(bundle)); |
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.
Maybe we could check the getCrossSigningStatus? and see that the identity is there and trusted?
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.
Done
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.
This causes the test to hang on OlmMachine::getIdentity
and I have 0 introspection on the rust side of things to debug 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.
Yes, getCrossSigningStatus
will want to fire off /keys/query
requests and wait for them to complete, so that is more of an integration-test thing.
That said: some integration tests here might be nice?
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Is this related to MSC4108? |
}, | ||
}; | ||
await rustCrypto.importSecretsForQrLogin(bundle); | ||
await expect(rustCrypto.exportSecretsForQrLogin()).resolves.toEqual(expect.objectContaining(bundle)); |
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, getCrossSigningStatus
will want to fire off /keys/query
requests and wait for them to complete, so that is more of an integration-test thing.
That said: some integration tests here might be nice?
I disagree. The docs on the methods I'm calling don't describe fully what it does so I cannot really form a full integration test without it being brittle with the exception of the assumption that importing and exporting round-trip successfully. |
I don't really understand your objection here, I'm afraid. The docs on the rust crate say that the methods import/export the cross-signing keys, and indeed your own documentation (yay, documentation, thank you!) says that of the new methods in So can't we test that? We could export the secrets bundle from one
I think a better argument is that these are very thin wrappers, and the cost/benefit of writing a complicated integration test is low, given the meat of the functionality should already be tested at the rust-sdk level. |
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
We already do. I exported a bundle from a test account & baked it into the test, import it and validate that exporting yields the same bundle once again. |
…hguy/oidc-qr-crypto
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
errr I seem to have pressed enter halfway through editing that comment, so sorry for the half-formed thoughts |
So we do. Apparently I need to read better. |
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.
Thanks. Sorry this took a while to review.
* Implementation of {@link CryptoApi#importSecretsBundle}. | ||
*/ | ||
public async importSecretsBundle( | ||
secrets: Parameters<NonNullable<CryptoApi["importSecretsBundle"]>>[0], |
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 still think there's way too much type magic going on here. As a caller of this function, how am I meant to build one of these things?
... I'm not going to block the PR further on it, though.
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.
As a caller of this function, how am I meant to build one of these things?
you shouldn't construct manually, only ever exported by the matching export function
I want to do some work in RustCrypto that will conflict with this, so merging |
Split out from #4134