Doesn't access database directly anymore but goes through AxolotlService
now to obtain list of fingerprints associated with an Account/Contact.
This should prevent orphaned keys littering the UI which previously
couldn't be removed through the Clear Devices function.
Together with 1c79982da84964c1d81179a0927d9cd1eadf53de this fixes#1393
There is no need to preemptively add the keys to the store oneself.
SessionBuilder will take care of this for us. What's more, this will
prevent IdentityKeys from otherwise invalid bundles to show up in our
UI.
If we detect our own ID is not in our own devicelist on receiving an
update, we reannounce ourselves. This used to have the side effect of
modifying the list of devices we thought were in the update set, causing
us to accidentally build a session with ourselves.
This lead to our own key being set to TRUSTED_INACTIVE, resulting in red
lock icons on messages sent by the own device.
We fix this by having publishOwnDeviceId() operate on a copy of the
original set. This commit also includes a db migration which deletes
sessions with oneself and sets own keys back to TRUSTED.
If PEP publish tries are repeatedly triggered by empty PEP updates, stop
attempting to publish after 3 tries. This should work around broken PEP
implementations in older ejabberd and OpenFire versions.
XmppAxolotlMessage is now entirely responsible for handling encryption
and decryption of messages, only leveraging XmppAxolotlSession as a
packing/unpacking primitive for payload keys.
Removed pseudo-dead session generation code step from prepareMessage
function, as sessions have been created by invoking the
TrustKeysActivity for a while now.
Added prepareKeyTransportMessage function, which creates a message with
no payload. The key that is packed into the header keyElements can then
be used for other purposes (e.g. encrypted file transfer).
Moves SQLiteAxolotlStore and XmppAxolotlSession into proper classes.
IdentityKeys trust statuses are now cached in an LruCache to prevent
hammering the database when rendering the UI.
We introduce a new trust state: INACTIVE. This state is intended for
old keys that have been removed.
When a TRUSTED device is removed from the PEP devicelist, it's status
will be set to INACTIVE. INACTIVE keys are shown in the UI as greyed
out, non-interactible key rows. Messages are not encrypted for INACTIVE
devices.
When an INACTIVE device reappears in PEP, or a message is received from
an INACTIVE device, it is set back to trusted.
Daniel Gultsch