* Start a new Olm sessions with a device when we get an undecryptable
message on it.
* Send a dummy message on that sessions such that the other end knows
about it.
* Re-send any outstanding keyshare requests for that device.
Also includes a unit test for megolm that isn't very related but came
out as a result anyway.
Includes https://github.com/matrix-org/matrix-js-sdk/pull/776
Fixes https://github.com/vector-im/riot-web/issues/3822
Previously the global flag was used as a way to completely ignore the per-room option. This commit makes the per-room and global settings be more flexible to allow users to, for example, blacklist unverified devices in all room with the exception of one or two. This is done by making the global setting a device-level default and the per-room option allowing for 3 states: true, false, and unset (use device default).
Signed-off-by: Travis Ralston <travpc@gmail.com>
* Fix a race in decrypting megolm messages
This fixes a race wherein it was possible for us to fail to decrypt a message,
if the keys arrived immediately after our attempt to decrypt it. In that case,
a retry *should* have been scheduled, but was not.
Fixes https://github.com/vector-im/riot-web/issues/5001.
* WORDS
* OlmDevice.hasInboundSessionKeys
* OlmDevice.getInboundGroupSessionKey
The latter means that MegolmDecryption.shareKeysWithDevice takes longer before
it sends out the keyshare, so means the unit test needed an update
... instead of having it call event.setClearData.
The main advantage of this is that it fixes a race condition, wherein apps
could see `event.isDecrypting()` to be true, but in fact the event had been
decrypted (and there was no `Event.decrypted` event on its way).
We're also fixing another race, wherein if the first attempt to decrypt failed,
a call to `attemptDecryption` would race against the first call and a second
attempt to decrypt would never happen.
This also gives a cleaner interface to MatrixEvent, at the expense of making
the `megolm` unit test a bit more hoop-jumpy.
when we receive a m.forwarded_room_key, add it to the crypto store, but
remember who forwarded it to us, so we can decide whether to trust them
separately.
These terms were somewhat confusing (and, in the case of megolm, misleading),
so replace them with explicit senderCurve25519Key and claimedEd25519Key fields.
In an attempt to make the rageshake logs a bit more useful, try to make the
logging a bit saner. Firstly, make sure we log every decryption failure, and
log it exactly once, rather than in several places. Also record when we receive
megolm keys. Also add some more explicit logging in the sync loop.
