search

gkdr / lurch

XEP-0384: OMEMO Encryption for libpurple.
GNU General Public License v3.0
289 stars 32 forks source link

OMEMO-enabled MUC loses offline messages when sent by pidgin #101

Open t2d opened 6 years ago

t2d commented 6 years ago

We tried a multi-user chat with 4 participants:

Without OMEMO everything works as expected. Every client receives offline messages of any other client.

If we enable OMEMO on all devices:

The test environment was a prosody 0.10 server installed with this role.

gkdr commented 6 years ago

I suspect this is related to the fact that lurch does not add a <body> with a fallback message, so the messages do not get saved and replayed by MUC history. Messages from people who are not present in the MUC at the time of MUC history replay are not decrypted because it is not possible to look up the sender's JID. The Conversation developer told me it implements a nice heuristic: check if there is a session with that device ID. They're not guaranteed to be unique without the JID, but it's probably worth a try.

So I think the client using Gajim was online when the MUC history replay happened - if that's not the case I'd be very surprised.

I do have a request though: Could you show me what a message from ChatSecure looks like?

t2d commented 6 years ago

Yes, all clients were always present during the history replay.

t2d commented 6 years ago

I believe this is what the ChatSecure message looks like (taken with Gajim during live muc):

<message xmlns="jabber:client" id="9B24BEA2-8C17-4B56-A4B0-36C8C23F67DB" type="groupchat" to="client@example.org/gajim.X0M4OAP6" from="test_omemo@conference.example.org/ChatSecure">
  <store xmlns="urn:xmpp:hints" />
  <encrypted xmlns="eu.siacs.conversations.axolotl">
    <header sid="1236947956">
      <key rid="876859048">MwohBX2oXTW3TMP24Rv+L7fZKZC0d0YpAGI76V0SE7u8iwIbEAAYACIwaL1yb2t5Li5oNnW6vHrY08eISu/uzfhDg2nwJhbBDaDwNyEhCb5C0/LvcdewlQV/ZoyVrqXsM0I=</key>
      <key rid="546442800">MwohBfe6/vlDjm3KZOTUt0NDzCRyOhvHB0gp6JOF/PQ+bJkAEAQYACIwR/ZpPpakEqCRnorb4Uc7HIwAYtLWpV1dx+aHfT9zqWsyCvRgI4HYPD5LecWHewg6RujbME2jgbQ=</key>
      <key rid="669082632">MwohBe0157ImPjjY/cNMD6ekzO6+kNqcafDM/YPrFHGuRYhyEAAYACIwePx3SLWPK/hk/h5EgedWZzgWnhpC4IFbdax1schNFoc0eOwkkSKBfNDI9IBFPwT1ZhS/FilVBoE=</key>
      <iv>JGTzQ8Pc1WbXdRJTluppAA==</iv>
</header>
    <payload>mQECHw==</payload>
</encrypted>
  <origin-id id="9B24BEA2-8C17-4B56-A4B0-36C8C23F67DB" xmlns="urn:xmpp:sid:0" />
</message>
gkdr commented 6 years ago

I wonder what the matter here is, as the ChatSecure messages also do not contain a body. libomemo does add a <store> hint, but it's the last element inside of the message instead of the first - shouldn't matter (I think), but maybe the Prosody module is being weird about it. The <origin-id> shouldn't cause such behaviour, but who knows. The _modmuc page doesn't have a lot of info.

I also looked into Prosody's _modmam, and it doesn't seem like it's being used on MUCs, so it should not be related to that.

t2d commented 6 years ago

To make MUC use MAM prosody uses mod_mam_muc

gkdr commented 6 years ago

Yeah, but it's not installed on your server, or is it somehow implicitly contained?

t2d commented 6 years ago

Sorry, the configuration is very confusing and the variables should be improved. It is loaded directly in the config to get to the correct component only.

gkdr commented 6 years ago

Oh, okay, that probably explains it. I was only looking at the README.

So I suppose the Gajim messages do have a <body>, so they're part of the regular MUC history and that's why Pidgin can decrypt them, but only if the sender is online at the time the history replay happens.

I don't understand why messages by Pidgin are ignored then though, since I do add the same hint as ChatSecure. Maybe because Pidgin can't do MAM and doesn't advertise it, but I'm not sure if that makes sense because it doesn't matter to recipients whether the sender can do MAM or not. Or maybe I should put the hint first just like ChatSecure. If you want, you can play around with the XMPP Console a bit and see if that helps. MAM support would be an entirely different matter though, there's so many moving parts I can't seem to get this somewhat stable even without it.