Add crypto methods for export and import of secrets bundle#4227
Add crypto methods for export and import of secrets bundle#4227
Conversation
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
| 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.
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.
Yes but with return types of any - see matrix-org/matrix-sdk-crypto-wasm#110
There was a problem hiding this comment.
This should be fixed on the wasm side; matrix-org/matrix-sdk-crypto-wasm#123 does so but it will need a release cycle :/
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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.
Maybe we could check the getCrossSigningStatus? and see that the identity is there and trusted?
There was a problem hiding this comment.
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.
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.
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. |
richvdh
left a comment
There was a problem hiding this comment.
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.
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.
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