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

Encrypt rooms' last messages #1718

Merged
merged 14 commits into from
Feb 21, 2023
Merged

Conversation

alfogrillo
Copy link
Contributor

@alfogrillo alfogrillo commented Feb 13, 2023

Description

This PR adds the AES encryption for rooms' last messages before they get stored into Core Data.

Fixes: element-hq/element-ios#7358

Before After
b a

@alfogrillo alfogrillo changed the title Encrypt room's last messages Encrypt rooms' last messages Feb 13, 2023
@alfogrillo alfogrillo requested a review from Anderas February 13, 2023 18:24
@codecov
Copy link

codecov bot commented Feb 13, 2023

Codecov Report

Base: 17.52% // Head: 17.63% // Increases project coverage by +0.11% 🎉

Coverage data is based on head (3117c9c) compared to base (2be6c58).
Patch coverage: 63.82% of modified lines in pull request are covered.

❗ Current head 3117c9c differs from pull request most recent head a3a5ea9. Consider uploading reports for the commit a3a5ea9 to get more accurate results

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #1718      +/-   ##
===========================================
+ Coverage    17.52%   17.63%   +0.11%     
===========================================
  Files          612      612              
  Lines        95993    96148     +155     
  Branches     40294    40353      +59     
===========================================
+ Hits         16826    16960     +134     
- Misses       78658    78674      +16     
- Partials       509      514       +5     
Impacted Files Coverage Δ
MatrixSDK/Data/Store/MXFileStore/MXFileStore.m 17.37% <ø> (ø)
MatrixSDK/Data/MXRoomLastMessage.m 32.70% <63.04%> (+15.14%) ⬆️
...aryStore/CoreData/Models/MXRoomLastMessageMO.swift 41.17% <100.00%> (-10.55%) ⬇️
...o/Algorithms/RoomEvent/MXRoomEventDecryption.swift 53.77% <0.00%> (-1.57%) ⬇️
...ypto/Verification/MXKeyVerificationManagerV2.swift 20.73% <0.00%> (-0.56%) ⬇️
MatrixSDK/Crypto/MXCrypto.m 2.06% <0.00%> (-0.01%) ⬇️
MatrixSDK/Utils/Media/MXMediaLoader.m 0.00% <0.00%> (ø)
...SDK/Crypto/Verification/MXKeyVerificationManager.m 0.00% <0.00%> (ø)
.../Crypto/KeyBackup/Engine/MXNativeKeyBackupEngine.m 0.00% <0.00%> (ø)
...ts/Crypto/Migration/MXCryptoMigrationV2Tests.swift 0.00% <0.00%> (ø)
... and 4 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

MatrixSDK/Data/MXRoomLastMessage.m Outdated Show resolved Hide resolved
MatrixSDK/Data/MXRoomLastMessage.m Outdated Show resolved Hide resolved
} else {
s_others = nil
s_attributedText = lastMessage.attributedText.map(NSKeyedArchiver.archivedData(withRootObject:))
Copy link
Contributor

@Anderas Anderas Feb 15, 2023

Choose a reason for hiding this comment

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

I think its a bit confusing that archiving of encrypted data happens in MXRoomLastMessage but unencrypted in MXRoomLastMessageMO ... it creates some assumptions about responsibilities that are not obvious from the API.

An alternative approach would be to simply expose archivedAttributedText getter on MXRoomLastMessage which would be used by MXRoomLastMessageMO directly. That way the latter will not need to perform any additional encryption checks

@@ -69,6 +69,8 @@ FOUNDATION_EXPORT NSString *const MXRoomLastMessageDataType;

- (instancetype)initWithEvent:(MXEvent *)event;

- (nullable NSData*)encryptedAttributedString;
Copy link
Contributor

Choose a reason for hiding this comment

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

As suggested below, I would rename this archivedAttributedText or attributedTextData and let it handle both encrypted and unencrypted variant, otherwise we are handling the archiving in two separate objects, depending on the encryption status.

Also I'd convert this into property (nonatomic, readonly, nullable) NSData *archivedAttributedText and move just below attributedText to make the API more consistent and clearer


if (_attributedText == nil && model.s_text)
{
_attributedText = [[NSAttributedString alloc] initWithString:model.s_text];
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this not change the existing behaviour? Previously if _attributedText was unset, it would not be created from model.s_text. It is not obvious to me whether text and attributedText are always variants of the same data or not. And if we always end up using attributedText whether it would be simpler to remove text entirely

@alfogrillo alfogrillo force-pushed the alfogrillo/fix_clear_last_message branch from 3d120bf to 9c2a2ce Compare February 16, 2023 15:53
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.

I think that changing the file store version would probably add enough changes that I'll leave finishing the review until then.

Also, I'm not super keen on the sensitiveData naming tbh - I think being more explicit and saying encryptedData when its encrypted and simply lastMessageData/Dictionary when its unencrypted would be clearer here.

MatrixSDK/Data/MXRoomLastMessage.h Outdated Show resolved Hide resolved
MatrixSDK/Data/MXRoomLastMessage.m Outdated Show resolved Hide resolved
_attributedText = sensitiveDataDictionary[kCodingKeyAttributedText];
_others = sensitiveDataDictionary[kCodingKeyOthers];
}
else // fallback logic for old database versions
Copy link
Member

Choose a reason for hiding this comment

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

You can completely avoid having to deal with old versions by incrementing kMXFileVersion in MXFileStore. It'll wipe the data and force a fresh sync when the user upgrades. Probably better than running the old way in parallel and avoids having to think about migrations etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Technically I didn't change the MXFileStore so I'm not sure this is clean.
Btw does it mean people will need to do a full sync potentially taking a lot of time (for account big as Matthew's one)?

@pixlwave
Copy link
Member

I've just twigged about the naming as sensitiveData is only encrypted for rooms with encryption enabled. Probably just lastMessageData or messageData to be clearer, otherwise ignore that comment 🙃

@alfogrillo
Copy link
Contributor Author

I've just twigged about the naming as sensitiveData is only encrypted for rooms with encryption enabled. Probably just lastMessageData or messageData to be clearer, otherwise ignore that comment 🙃

I don't know, names like these look confusing to me on types that already call themself MXRoomLastMessage. 😅
Btw the reasoning is that the sensitive data is always sensitive, in encrypted rooms we encrypt it.

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.

LGTM, chatted about the file store versions offline.

@alfogrillo alfogrillo merged commit e90403a into develop Feb 21, 2023
@alfogrillo alfogrillo deleted the alfogrillo/fix_clear_last_message branch February 21, 2023 09:33
Copy link
Contributor

@Anderas Anderas left a comment

Choose a reason for hiding this comment

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

This looks so much clearer now 👍

error:&error];

if (error) {
MXLogDebug(@"[MXRoomLastMessage] did fail to archive sensitiveDataDictionary. Error: %@", error.description);
Copy link
Contributor

Choose a reason for hiding this comment

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

For future reference: errors are best logged via MXLogErrorDetails which will also send them to Sentry (if enabled), or even MXLogFailureDetails if we do not expect this error to ever occur

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.

Encrypt last room message in MXCoreDataRoomsSummaryStore
3 participants