Skip to content
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

Merged
merged 8 commits into from
Jun 5, 2024

Conversation

t3chguy
Copy link
Member

@t3chguy t3chguy commented Jun 3, 2024

Split out from #4134

Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Copy link
Member

@BillCarsonFr BillCarsonFr left a 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 {
Copy link
Member

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?

Copy link
Member Author

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Member

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 :/

Copy link
Member

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)?

Copy link
Member Author

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

src/crypto/index.ts Outdated Show resolved Hide resolved
},
};
await rustCrypto.importSecretsForQrLogin(bundle);
await expect(rustCrypto.exportSecretsForQrLogin()).resolves.toEqual(expect.objectContaining(bundle));
Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member Author

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.

Copy link
Member

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?

@t3chguy t3chguy self-assigned this Jun 3, 2024
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
@richvdh
Copy link
Member

richvdh commented Jun 3, 2024

Is this related to MSC4108?

},
};
await rustCrypto.importSecretsForQrLogin(bundle);
await expect(rustCrypto.exportSecretsForQrLogin()).resolves.toEqual(expect.objectContaining(bundle));
Copy link
Member

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?

src/crypto-api.ts Outdated Show resolved Hide resolved
src/crypto-api.ts Outdated Show resolved Hide resolved
src/crypto-api.ts Outdated Show resolved Hide resolved
src/crypto-api.ts Outdated Show resolved Hide resolved
src/crypto-api.ts Outdated Show resolved Hide resolved
src/crypto-api.ts Outdated Show resolved Hide resolved
src/rust-crypto/rust-crypto.ts Outdated Show resolved Hide resolved
@t3chguy
Copy link
Member Author

t3chguy commented Jun 3, 2024

Is this related to MSC4108?

That is one consumer of such functions, but the Crypto crate doesn't seem to state that it is specific to MSC4108 so neither will this implementation be. Updated.

image

@t3chguy
Copy link
Member Author

t3chguy commented Jun 3, 2024

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.

Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
@t3chguy t3chguy changed the title Add crypto methods for OIDC QR code login Add crypto methods for export and import of secrets bundle Jun 3, 2024
@richvdh
Copy link
Member

richvdh commented Jun 4, 2024

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 CryptoApi.

So can't we test that? We could export the secrets bundle from one MatrixClient, and import it into another, and then check that the second client has the same cross-signing keys as the first.

Frankly, if your argument is "I can't write an integration test because I don't understand what it dos (edit: removed this, it wasn't what I meant to say)

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>
@t3chguy
Copy link
Member Author

t3chguy commented Jun 4, 2024

We could export the secrets bundle from one MatrixClient, and import it into another, and then check that the second client has the same cross-signing keys as the first.

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.

Signed-off-by: Michael Telatynski <7t3chguy@gmail.com>
@richvdh
Copy link
Member

richvdh commented Jun 5, 2024

errr I seem to have pressed enter halfway through editing that comment, so sorry for the half-formed thoughts

@richvdh
Copy link
Member

richvdh commented Jun 5, 2024

We could export the secrets bundle from one MatrixClient, and import it into another, and then check that the second client has the same cross-signing keys as the first.

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.

So we do. Apparently I need to read better.

Copy link
Member

@richvdh richvdh left a 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],
Copy link
Member

@richvdh richvdh Jun 5, 2024

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.

Copy link
Member Author

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

@richvdh
Copy link
Member

richvdh commented Jun 5, 2024

I want to do some work in RustCrypto that will conflict with this, so merging

@richvdh richvdh added this pull request to the merge queue Jun 5, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 5, 2024
@t3chguy t3chguy added this pull request to the merge queue Jun 5, 2024
Merged via the queue into develop with commit a3cea8c Jun 5, 2024
27 checks passed
@t3chguy t3chguy deleted the t3chguy/oidc-qr-crypto branch June 5, 2024 09:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants