crypto: Fix bugs in processing incoming encrypted to-device messages #5763
Conversation
richvdh
force-pushed
the
rav/history_sharing_exclude_insecure_devices
branch
from
a364d10 to
0a18741
Compare
CodSpeed Performance ReportMerging #5763 will not alter performanceComparing Summary
|
`Account::parse_decrypted_to_device_event` is getting a bit big and unwieldy, so factor out the bit that attempts to find the sending device. (Also, remove an outdated TODO.)
richvdh
force-pushed
the
rav/history_sharing_exclude_insecure_devices
branch
from
0a18741 to
28beb91
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #5763 +/- ##
==========================================
+ Coverage 88.42% 88.44% +0.01%
==========================================
Files 360 360
Lines 99796 99842 +46
Branches 99796 99842 +46
==========================================
+ Hits 88244 88301 +57
+ Misses 7411 7399 -12
- Partials 4141 4142 +1 ☔ View full report in Codecov by Sentry. |
Currently, when we receive a room key bundle to-device event, we don't look up the sender device at all, meaning that the message is then marked as "from missing device", which means that if you turn on "exclude insecure devices", the message is dropped. This patch changes the logic so that room key bundle to-device events are treated the same way as most other to-device events (except room keys, which continue to be special). Fixes: #5613, although the integration test now fails because instead we hit #5768.
I'm going to need to suppress `sender_device_keys` for more tests, so pull out a test helper to help with this.
…per` No need to convert the event content to a to-device request, and then convert back again.
richvdh
force-pushed
the
rav/history_sharing_exclude_insecure_devices
branch
from
fbe146a to
c6d1b60
Compare
richvdh
changed the title
| (None, Some(sender_device_keys)) => { | ||
| // We have already validated the signature on `sender_device_keys`, so this | ||
| // try_into cannot fail. | ||
| let sender_device_data = sender_device_keys.try_into().unwrap(); |
There was a problem hiding this comment.
No naked unwraps please, use an expect() to explain why it can't fail.
Alternatively, is there a good reason to not do this conversion in check_sender_device_keys() so the expect() isn't necessary at all?
There was a problem hiding this comment.
I'll replace this with an expect for now, but it's my opinion that there should be a way to convert a DeviceKeys whose signature we have already checked into a DeviceData (so, a DeviceData::from_validated_device_keys or similar): this isn't the only place we have to do it.
If we really want to track whether the signature has been checked via the type system, we should do so with a ValidatedDeviceKeys which wraps DeviceKeys, without all the other clutter that comes with DeviceData.
Alternatively, is there a good reason to not do this conversion in
check_sender_device_keys()so theexpect()isn't necessary at all?
It just feels like a bit of a confusing API for check_sender_device_keys to wrap the DeviceKeys with all this other data which we're probably going to throw away, and to provide a bunch of methods which don't really make sense.
…sages When receiving an encrypted to-device message, if the sender device is not in the store, but the event includes `sender_device_keys`, use `sender_device_keys` to do the verification checks etc. Fixes: #5768
Add a test to ensure that history-sharing still works when "exclude insecure devices" is enabled.
richvdh
force-pushed
the
rav/history_sharing_exclude_insecure_devices
branch
from
903f4ce to
01e2e48
Compare
2 participants
This PR fixes a pair of bugs around how device verification on incoming encrypted to-device messages. See individual commits for more details.
Fixes: #5613
Fixes: #5768