Accept key backups as usable if they're signed with the master cross-signing key

[bradtgmurray]

Accept key backups if they're signed by the master cross-signing key.

Used matrix-js-sdk as a reference which accepts it as usable if either the signing device is verified or it's the cross-signing key. https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/crypto/backup.ts#L426-L433

Signed-off-by: Brad Murray [email protected]

Pull Request Checklist

• Pull request is based on the develop branch
• Pull request contains a changelog file in ./changelog.d. See https://github.com/matrix-org/matrix-ios-sdk/blob/develop/CONTRIBUTING.md#changelog
• Pull request includes a sign off

[Anderas]

Hi Brad, thanks for the contribution. I made one comment regarding ensuring we do indeed have the master key when trusting a backup, and it would be also great to add a test case if possible for this, for instance in MXCryptoBackupTests

[Anderas]

The existing parent else branch does not ensure that the deviceId is indeed a master key (it only mentions it in a comment), as opposed to other type of key. Could you please change the else // Try interpreting it as the MSK public key into something like else if ([deviceId isEqualToString:masterKey])? The master key can be obtained for instance as crypto.crossSigning.myUserCrossSigningKeys.masterKeys.keys. See also Android implementation for reference.

If the comparison check fails, we can log that as another issue.

Additionally it may be worth renaming the deviceId local variable into deviceIdOrCrossSigningKey, otherwise the name can be misleading

[bradtgmurray]

Only a month and a half later I've finally addressed this feedback, thanks @Anderas !

[Anderas]

Thanks for making the change. I see that we will now be adding a signature object even if the master key verification did not succeed, but it will be set as invalid (plus this copies js / android behaviour) so it sounds good to me

[bradtgmurray]

Repurposed an existing test. Based on the name it seems to have been wanting to test MSKTrust, but because the valid device signature was marking the device usable it was hiding the bug that I'm fixing with this PR. Now the only signature on the backup is the MSK.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 12.49%. Comparing base (2b96b99) to head (43c107e).
⚠️ Report is 903 commits behind head on develop.

Files with missing lines	Patch %	Lines
MatrixSDK/Crypto/KeyBackup/MXKeyBackup.m	0.00%	17 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1492      +/-   ##
===========================================
- Coverage    12.49%   12.49%   -0.01%     
===========================================
  Files          521      521              
  Lines        85051    85056       +5     
  Branches     36216    36219       +3     
===========================================
  Hits         10626    10626              
- Misses       74039    74044       +5     
  Partials       386      386              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bradtgmurray]

Strange, these tests seem to pass locally, any ideas?

[Anderas]

The new test looks good, however it might be better to create it as copy and leave testCrossSigningMSKTrustForKeyBackupVersion as is, otherwise we loose the test case for getting a device signature (XCTAssertEqual(keyBackupVersionTrust.signatures.count, 2))

[Anderas]

Thanks for making the change. I see that we will now be adding a signature object even if the master key verification did not succeed, but it will be set as invalid (plus this copies js / android behaviour) so it sounds good to me

[Anderas]

Strange, these tests seem to pass locally, any ideas?

Unfortunatelly crypto + integration tests are very flaky, we are in the process of enabling + fixing them. I'd say make sure that they pass on your local branch, and optionally you can rerun the GitHub tests a few times. We cannot just turn them off because locally they are not as flaky and thus hard to spot the misbehaving ones.