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

Subclass MXCrypto to enable work-in-progress Rust sdk #1496

Merged
merged 6 commits into from
Jun 15, 2022

Conversation

Anderas
Copy link
Contributor

@Anderas Anderas commented Jun 9, 2022

To avoid long-running feature branch when implementing Matrix Rust SDK aka Element-R, I'd like to start merging small changes into develop that are well isolated and cannot be shipped to production by accident. In particular all newly added code is hidden both behind a build flag as well as behind DEBUG compiler macro, so the new code cannot be accidentally used and shipped to production builds.

This particular PR sets up the skeleton for new rust-based implementation by overriding MXCrypto and all of its methods. This has both benefits and risks:

  • no need to do any risky refactor across the rest of the application (for example by definining shared protocol)
  • existing integration tests can still run unaltered, and validate that future Rust implementation works as expected
  • potential risk: compiler does not ensure that each MXCrypto's method is overriden, so if new public API was added to MXCrypto, this would not be automatically picked up by MXCryptoV2. This is a small risk, as the code is not meant for production yet, and when productionizing, more safety measures will be put in place.

Finally note this PR does not yet add any actual Rust library, merely sets the stage up.

@@ -7237,6 +7243,7 @@
MACOSX_DEPLOYMENT_TARGET = 10.10;
MTL_ENABLE_DEBUG_INFO = YES;
ONLY_ACTIVE_ARCH = YES;
OTHER_SWIFT_FLAGS = "-D DEBUG";
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Note the addition of this flag, otherwise DEBUG macro in Swift is incompatible with the one in objective-c


import Foundation

#if DEBUG
Copy link
Contributor Author

Choose a reason for hiding this comment

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

The entire MXCryptoV2 class is wrapped in DEBUG macro so it cannot be instantiated / used in production builds by accident

@@ -200,10 +200,22 @@ NS_ASSUME_NONNULL_BEGIN
Enable sharing of session keys for an immediate historical context (e.g. last 10-20 messages)
when inviting a new user to a room with shared history.

@remark YES by default.
@remark NO by default.
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Unrelated change, docs were stating incorrect default value

@Anderas Anderas requested review from a team, pixlwave, manuroe and BillCarsonFr and removed request for a team June 9, 2022 15:20
Copy link
Member

@pixlwave pixlwave left a 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 and the use of the build setting and compiler macro sounds sane. Two minor comments:

  • Should we be concerned about other library users if they also have the DEBUG compiler macro set? I think the answer is no, but seems worth asking in case.
  • The doc comments in the Swift file should probably use /// instead of /** */

@Anderas
Copy link
Contributor Author

Anderas commented Jun 13, 2022

* Should we be concerned about other library users if they also have the `DEBUG` compiler macro set? I think the answer is no, but seems worth asking in case.

Could you elaborate on what the worry is pls? To be clear, having DEBUG configuration by itself is not enough to use the new Crypto, one also has to set the build flag to true, the flag is just prevent submitting anything to production.

@Anderas Anderas force-pushed the andy/rust_pt1_interface branch from 6981632 to 75af590 Compare June 13, 2022 08:40
@@ -3643,7 +3643,7 @@ - (void)validateEncryptionStateConsistency
if (!crypto)
{
#ifdef MX_CRYPTO
MXLogFailure(@"[MXRoom] checkEncryptionState: Crypto module is not present");
MXLogError(@"[MXRoom] checkEncryptionState: Crypto module is not present");
Copy link
Contributor Author

Choose a reason for hiding this comment

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

There are some tests where these conditions actually occur. I do not yet know whether this is expected or not, either way the assertion will stop the tests. Temporarily switching to logging errors instead of failures and will investigate the failing tests individually.

@pixlwave
Copy link
Member

pixlwave commented Jun 13, 2022

Could you elaborate on what the worry is pls? To be clear, having DEBUG configuration by itself is not enough to use the new Crypto, one also has to set the build flag to true, the flag is just prevent submitting anything to production.

It was only if using DEBUG meant further PRs might introduce small changes that were behind the DEBUG configuration but not also the build flag. Seemed unlikely but asked in case. :)

Copy link
Contributor

@manuroe manuroe left a comment

Choose a reason for hiding this comment

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

Looks smart to me :D

MatrixSDK/Crypto/MXCryptoV2.swift Outdated Show resolved Hide resolved
@Anderas
Copy link
Contributor Author

Anderas commented Jun 15, 2022

Could you elaborate on what the worry is pls? To be clear, having DEBUG configuration by itself is not enough to use the new Crypto, one also has to set the build flag to true, the flag is just prevent submitting anything to production.

It was only if using DEBUG meant further PRs might introduce small changes that were behind the DEBUG configuration but not also the build flag. Seemed unlikely but asked in case. :)

I see. Yea I do not currently anticipate such change, but will have to be careful about this.

I would actually like to get rid of the feature flag and replace it with compiler macro altogether (e.g. MX_CRYPTO_V2), so that the value cannot be mutated at runtime. The trouble here is that it needs to be usable from both obj-c and Swift and macros in each aren't currently mutally interchangable. The only reason DEBUG works this way is because it is manually set in build settings of the project. I may try to find another solution for this in the next PR, where the creation of the MXCryptoV2 happens in some swift extension of MXCrypto.m, which means they could refer to the same Swift-only compiler macro.

@@ -71,7 +71,6 @@
"MXCryptoTests\/testMXDeviceListDidUpdateUsersDevicesNotification",
"MXCryptoTests\/testMXSDKOptionsEnableCryptoWhenOpeningMXSession",
"MXCryptoTests\/testMXSessionEventWithEventId",
"MXCryptoTests\/testMultipleDownloadKeys",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

One of those tests that seems a bit flaky, sometimes passes sometimes not. Disabling for now to unblock other work, will investigate separately.

@Anderas Anderas merged commit 4080107 into develop Jun 15, 2022
@Anderas Anderas deleted the andy/rust_pt1_interface branch June 15, 2022 16:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants