Unknown opened 3 years ago
|
|
This message which is presented to you is most likely sent by another client. It is a "placeholder" message to be displayed if receiving client does not support OMEMO. Siskin IM supports OMEMO and if it would fail to decrypt the message it would present a different message. This message which you see may only be presented if Siskin IM was unable to "find" OMEMO encryption elements in the message which you received. That is why I assume that either message is modified by some entity after being sent by the sender and before it was received by your device, or the sender sent a malformed message. If you know that usually only one client/user sends those messages, could you find out which XMPP client software is being used? |
|
Most users in the group use Conversations and/or Gajim. As I said, the problem is not limited to one specific user. |
|
In one private MUC with OMEMO my profanity often fails to encrypt to the Apple participant using Siskin. I did not yet find out why profanity sometimes stumbles to encrypt to siskin. |
|
A Siskin user reported a similar problem: only some OMEMO messages can't be decrypted. We may have found steps to reproduce:
So it looks like Siskin can't decrypt OMEMO messages from MAM, when the sender is offline at the time of MAM retrieval. Does it sound plausible? |
|
What is the actual message shown in SiskinIM? To me, it looks like a case when the message was not encrypted for Alice's SiskinIM by Bob when her device was offline (encrypted for occupants (currently connected users) instead of room members). |
|
Which client Bob uses? |
|
There were many Bobs :) at least, one Dino, one Gajim, and probably one Conversations All 3 of them were previously used in the same group chat and Alice was able to decrypt their messages. FYI: The server hosting the group chat is chapril.org running ejabberd 21.01. |
|
Do you by any chance known how long it was since Alice went offline till Bob tried to send her a message. Error -1008 suggests that there is no OMEMO session between Alice and Bob, just like there was a message initiating this session that was lost.
When was that? What is different now? |
|
Long enough to make Alice appear offline. In ejabberd logs, Alice's session is explicitly closed:
I'm not really familiar with how OMEMO sessions work. From the way you speak of it, it seems that OMEMO is only possible when both participants are online. Right?
When the group chat was created, both Alice and Bob were online and chatting with OMEMO. Then, when Bob writes new messages while Alice is offline (happens every time the iphone goes asleep), Alice won't be able to read those messages when she comes back online. And while she's online, she is able to read new OMEMO messages from Bob. That's why I suspect the issue only occur when retrieving OMEMO messages from MAM. |
|
No, it will work even if participants are offline. However, it is possible that the OMEMO session was invalidated (and/or recreated) before the message was received from MAM. That would end up with a missing OMEMO session in Siskin IM. The question is why this happened. Which version of SiskinIM is in use? From testflight or from the AppStore? |
|
Alice uses Siskin from the AppStore. |
|
This issue is 100% reproducible in a private room on muc.chapril.org. Could you create a private room on muc.tigase.org to compare the results? |
Describe the bug In group chats as well as in private messages, sometimes my client seems not to be able to deal with OMEMO encrypted messages. The behaviour seems to happen randomly. Instead of the message, I get presented with the following text: You received a message encrypted with OMEMO but your client doesn't support OMEMO. In 95% of the cases however, everything works just fine, but this issue keeps coming up from time to time. In group chats, only one person (not always the same) causes the problems, the other persons' messages don't put up any issues. After I reply in chat stating that I can't read the message, all following messages by that person are readable just fine. The OMEMO lock symbol is always present, even in the "warning" messages.
To Reproduce Steps to reproduce the behavior:
Expected behavior No OMEMO issues
Screenshots N/A
Details (please complete the following information):
Additional context N/A