-
Notifications
You must be signed in to change notification settings - Fork 749
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
Defensive coding to ensure encryption when room was once e2e #5136
Conversation
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.
One remark otherwise LGTM
* But the crypto layer has additional guaranty to ensure that encryption would never been reverted | ||
* It's defensive coding out of precaution (if ever state is reset) | ||
*/ | ||
fun shouldEncryptInRoom(roomId: String?): Boolean |
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.
If we have roomId as nullable here we should do the same for isRoomEncrypted I guess
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.
roomId in event are optional (but almost always there), all codes ends up having optional, and function call wrapped in a let with an elvis.
It's a bit annoying, I let the caller pass an optional and return false if null in the code. I find the ending code more readable
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.
Yeah I know...the fact is I think we shouldn't have nullable roomId in Event :/
Matrix SDKIntegration Tests Results:
|
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.
Some thoughts
* But the crypto layer has additional guaranty to ensure that encryption would never been reverted | ||
* It's defensive coding out of precaution (if ever state is reset) | ||
*/ | ||
fun shouldEncryptInRoom(roomId: String?): Boolean |
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.
Do we really need to expose this to the application?
Using the CryptoStore may be enough internally
Also we can have isRoomEncrypted
which return false
and shouldEncryptInRoom
which return true
. How the UI should react in this case? Updating the UI will be maybe for another PR so this is the rational to expose that API?
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.
The source of trust is still the presence or not of a state event of type m.room.encryption, so the UI will always reflect that. For example UI will detect a missconfigured encryption.
The shouldEncrypt is more some internal protection, and should not be reflected on UI.
Also I don't expose it anymore
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.
It's still in the interface, can you remove it?
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.
Done
@@ -303,7 +303,7 @@ internal class DefaultSendService @AssistedInject constructor( | |||
private fun internalSendMedia(allLocalEchoes: List<Event>, attachment: ContentAttachmentData, compressBeforeSending: Boolean): Cancelable { | |||
val cancelableBag = CancelableBag() | |||
|
|||
allLocalEchoes.groupBy { cryptoSessionInfoProvider.isRoomEncrypted(it.roomId!!) } | |||
allLocalEchoes.groupBy { cryptoStore.roomWasOnceEncrypted(it.roomId!!) } |
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.
We still have !!
here, this is not ideal :/ but this is not Event coming from the wild so I think it's fine...
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.
Yes it's a private function, so acceptable :/
6424ec6
to
48fffc3
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.
Thanks for the update!
import org.matrix.android.sdk.internal.crypto.store.db.model.CryptoRoomEntityFields | ||
import org.matrix.android.sdk.internal.util.database.RealmMigrator | ||
|
||
// Version 14L Update the way we remember key sharing |
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 comment need to be updated (or removed). I can delete it on develop.
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.
(95c00a1)
Some defensive coding on the crypto side to ensure that a room that was once known locally has encrypted (with a valid algorithm) will still stays encrypted.
This is very defensive and resist to
state resets
variationsIn the CryptoRoom entity we add a new boolean to remember if the room was once encrypted with a valid algorithm.
We still store the alg got from the state, in order to properly give feedback of misconfigured room