-
Notifications
You must be signed in to change notification settings - Fork 216
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
Conversation
Codecov ReportBase: 17.52% // Head: 17.63% // Increases project coverage by
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
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. |
} else { | ||
s_others = nil | ||
s_attributedText = lastMessage.attributedText.map(NSKeyedArchiver.archivedData(withRootObject:)) |
There was a problem hiding this comment.
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
MatrixSDK/Data/MXRoomLastMessage.h
Outdated
@@ -69,6 +69,8 @@ FOUNDATION_EXPORT NSString *const MXRoomLastMessageDataType; | |||
|
|||
- (instancetype)initWithEvent:(MXEvent *)event; | |||
|
|||
- (nullable NSData*)encryptedAttributedString; |
There was a problem hiding this comment.
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
MatrixSDK/Data/MXRoomLastMessage.m
Outdated
|
||
if (_attributedText == nil && model.s_text) | ||
{ | ||
_attributedText = [[NSAttributedString alloc] initWithString:model.s_text]; |
There was a problem hiding this comment.
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
3d120bf
to
9c2a2ce
Compare
There was a problem hiding this 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.m
Outdated
_attributedText = sensitiveDataDictionary[kCodingKeyAttributedText]; | ||
_others = sensitiveDataDictionary[kCodingKeyOthers]; | ||
} | ||
else // fallback logic for old database versions |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)?
...ata/MXCoreDataRoomSummaryStore.xcdatamodeld/MXRoomSummaryCoreDataStore2.xcdatamodel/contents
Show resolved
Hide resolved
I've just twigged about the naming as |
Co-authored-by: Doug <[email protected]>
I don't know, names like these look confusing to me on types that already call themself |
There was a problem hiding this 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.
There was a problem hiding this 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); |
There was a problem hiding this comment.
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
Description
This PR adds the AES encryption for rooms' last messages before they get stored into Core Data.
Fixes: element-hq/element-ios#7358