finishing (sending a key transport message in response to pre key message) as
well as reparing sessions will leak resource and availability and might in
certain situations in group chat leak the Jabber ID.
Therefor we disable that. Leaking resource might not be considered harmful by
a lot of people however we have always doing similar things with receipts.
XML and by inheritence XMPP has the feature of transmitting multiple language
variants for the same content. This can be really useful if, for example, you
are talking to an automated system. A chat bot could greet you in your own
language.
On the wire this will usually look like this:
```xml
<message to="you">
<body>Good morning</body>
<body xml:lang="de">Guten Morgen</body>
</message>
```
However receiving such a message in a group chat can be very confusing and
potentially dangerous if the sender puts conflicting information in there and
different people get shown different strings.
Disabeling support for localization entirely isn’t an ideal solution as on
principle it is still a good feature; and other clients might still show a
localization even if Conversations would always show the default language.
So instead Conversations now shows the displayed language in a corner of the
message bubble if more than one translation has been received.
If multiple languages are received Conversations will attempt to find one in
the language the operating system is set to. If no such translation can be
found it will attempt to display the English string.
If English can not be found either (for example a message that only has ru and
fr on a phone that is set to de) it will display what ever language came first.
Furthermore Conversations will discard (not show at all) messages with with
multiple bodies of the same language. (This is considered an invalid message)
The lanuage tag will not be shown if Conversations received a single body in
a language not understood by the user. (For example operating system set to
'de' and message received with one body in 'ru' will just display that body as
usual.)
As a guide line to the user: If you are reading a message where it is important
that this message is not interpreted differently by different people (like a
vote (+1 / -1) in a chat room) make sure it has *no* language tag.
when receiving a FCM push message for a channel the user is no longer in (this can happen when the disable command failed) an attempt will be made to explicitly unregister from the app server (which in turn will then send item-not-found on next push)
after receiving a SignalMessage that can’t be decrypted because of broken sessions
Conversations will attempt to grab a new pre key bundle and send a new PreKeySignalMessage
wrapped in a key transport message.
apparently using conscrypt on Android below version 7? throws an exception when using 16 byte IVs.
so we now use BC when ever possible (excluding api 28)
we don’t know why Conscrypt behaves differently on various android versions
When receiving a PGP message which is not encrypted with YOUR key,
OpenKeychain shows a dialog, which tells you the private key to decrypt
the message is unavailable. However, Conversations won't give up
decrypting the message. So whether the subsequent messages are
decryptable or not, the decryption is blocked at the current message.
The commit fixes the bug in this way: Give up the current message when
the decryption intent is cancelled, so that subsequent messages can be
handled.
The self signed certificates created by OpenFire (Not sure if other
certs are affected as well) will crash the Java/Android TLS stack when
accessing getSubjectAlternativeNames() on the the peer certificate.
This usually goes unnoticed in other applications since the
DefaultHostnameVerifier checkes the CN first. That however is a
violation of RFC6125 section 6.4.4 which requires us to check for the
existence of SAN first.
This commit adds a work around where in self signed certificates we
check for the CN first as well. (Avoiding the call to
getSubjectAlternativeNames())
