OMEMO - Sending messages to myself, 'OMEMO not supported' #1595

daeluk · 2021-09-02T21:41:53Z

Expected Behavior

Sending OMEMO encrypted messages to my own JID should only contain messages sent from any of my devices.

Current Behavior

Currently, when sending messages to my own JID I get spurious "your Client doesn't support OMEMO" messages,
in addition to the original, encrypted (~) message. This happens both with sent and received messages.
This doesn't happen in any other clients (tested with Conversations and Gajim). All of my device fingerprints are trusted.

Steps to Reproduce (for bugs)

/msg <own JID>
/omemo start
/omemo trust <known fingerprints>
Write a message

Here is an example conversation:

23:20:00 ~ me: Hello from profanity
23:20:00 - me: You received a message encrypted with OMEMO but your client doesn't support OMEMO.
23:24:28 ~ me: Hello from Conversations
23:24:28 - me: I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo

Context

Sometimes it's useful to be able to write a notes to yourself, e.g. to easily share text between phone and pc.

Environment

Give us the version and build information output generated by profanity -v

Profanity, version 0.11.0dev.master.c89e3126
Copyright (C) 2012 - 2019 James Booth <boothj5web@gmail.com>.
Copyright (C) 2019 - 2021 Michael Vetter <jubalh@iodoru.org>.
License GPLv3+: GNU GPL version 3 or later <https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libmesode
Desktop notification support: Disabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.16.0)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.8.11)
GTK icons/clipboard: Enabled

Operating System/Distribution
OpenBSD -current (7.0 beta)
glib version
glib2-2.68.4

The text was updated successfully, but these errors were encountered:

jubalh · 2021-09-03T10:18:41Z

All of my device fingerprints are trusted.

Can you please check your device key and see if it is indeed in the list of trusted keys? I mean: it could be that profanity lists a couple of keys but actually the key from the other client is not listed there because it couldn't find it.

daeluk · 2021-09-04T23:06:14Z

All the keys listed match the ones on my other clients. :/

jubalh · 2021-09-05T09:34:20Z

That is very weird.
Also I can't reproduce that.
@DebXWoody @paulfariello any ideas?

daeluk · 2021-09-05T10:33:20Z

I was also trusting this profanity session's key, and thought maybe that was causing it, but untrusting my own key doesn't help.

daeluk · 2021-09-05T10:44:58Z

Also happens on my alpine raspberry pi running:

Profanity, version 0.11.0
Copyright (C) 2012 - 2019 James Booth <boothj5web@gmail.com>.
Copyright (C) 2019 - 2021 Michael Vetter <jubalh@iodoru.org>.
License GPLv3+: GNU GPL version 3 or later <https://www.gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Build information:
XMPP library: libmesode
Desktop notification support: Disabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.15.1)
OMEMO support: Enabled
C plugins: Disabled
Python plugins: Disabled
GTK icons/clipboard: Disabled

paulfariello · 2021-09-05T13:39:25Z

Isn’t it a mam issue or something like that?

One device cannot encrypt messages for itself (known protocol limitation).

My guess: the first one is simply the one being sent (thus we have the cleartext). The second message is received from the server thus we don’t have the cleartext and we can’t decrypt it.

jubalh · 2021-09-05T13:44:24Z

@daeluk what does /mam say?

paulfariello · 2021-09-06T12:44:36Z

@daeluk could you also confirm with /xmlconsole that you receive the message you have sent?

Rethinking about the issue, I'm not sure it's MAM related. Maybe it's an issue with message ID that is not preserved by the server.
@daeluk which server are you using?

jubalh · 2021-09-06T12:56:22Z

MAM is in experimental state. So if we get a new message we display that message. If it was already encrypted and can't be encrypted again this is supposed to happen.
We don't compare it yet with what we have in the database. Later we want to compare the id and actually display MAM from what we have already in the DB and only fill the whole in the DB from MAM.

mwuttke wanted to rewrite the UI code so that we can do this more easily. Unfortunately he vanished and I didn't find the time yet to start this.

So if it is true that @daeluk has enabled MAM than this issue is expected and is because of the experimental state of MAM integration in Profanity.

daeluk · 2021-09-08T21:21:12Z

Hi sorry for the late response.
I definitely enabled mam recently, but I've been experiencing this issue since the very first time I used profanity and hadn't enabled mam yet. That was on v0.10 which AFAIK didn't yet support mam.

/xmlconsole does report sending and receiving a message, followed by sending and receiving the client doesn't support OMEMO message.

I am using prosody-0.11.9 on an OpenBSD 6.9-stable server.

Looking at the log I see the following, the timestamps corresponding to the messages I sent to myself:

08/09/2021 23:06:29: prof: WRN: [OMEMO][RECV] received a message with no corresponding key
08/09/2021 23:07:28: prof: WRN: [OMEMO][RECV] received a message with no corresponding key
08/09/2021 23:07:56: prof: WRN: [OMEMO][RECV] received a message with no corresponding key
08/09/2021 23:08:04: prof: WRN: [OMEMO][RECV] received a message with no corresponding key

jubalh · 2021-09-09T07:05:35Z

I am using prosody-0.11.9 on an OpenBSD 6.9-stable server.

I assume this is a typo and 0.11.0 is what you mean :)

08/09/2021 23:06:29: prof: WRN: [OMEMO][RECV] received a message with no corresponding key

Then it is not MAM.
@paulfariello is this also fixed by #1591 ?

jubalh · 2021-09-09T07:37:37Z

@daeluk do you know how to compile profanity yourself? It would be helpful if you could try latest master and see if it works there.
We plan to release 0.11.1 soon (only one bug left). And if this is fixed in master it would be nice.

paulfariello · 2021-09-09T09:28:54Z

I don't see why #1591 would impact this issue, but trying with latest master is never a bad idea.

jubalh · 2021-09-09T09:38:18Z

received a message with no corresponding key

how can it happen that there is no key?

daeluk · 2021-09-11T17:39:07Z

I assume this is a typo and 0.11.0 is what you mean :)

Nope 0.11.9 is what I meant. That was about the xmpp server prosody not profanity :D

It would be helpful if you could try latest master and see if it works there.

Still same situation on latest master 0.11.0dev.master.1dbe1a33.

DebXWoody · 2021-09-11T17:49:25Z

On Sa, 11.09.2021 10:39:18, Jakob Rotchteine wrote: > It would be helpful if you could try latest master and see if it works there. Still same situation on latest master `0.11.0dev.master.1dbe1a33`.

Can you join the profanity Chat and send me a PM?

DebXWoody · 2021-09-12T08:20:20Z

Maybe an issue with disco info request. I will drop a mail on the mailinlist with more information about "disco and OMEMO". The reason of missing disco info may a problem with TLS - not sure. Let's see if a renewal+adding subdomain will solve this issue.

…

-- Stefan

jubalh · 2021-09-13T08:37:11Z

Copy of the message so that we have all in one place:

To: Mailingliste profanity <profanity@lists.notraces.net>
Subject: [profanity] OMEMO and disco
Date: Sun, 12 Sep 2021 14:19:39 +0200

Hello,

# Login and OMEMO

just after login we calling connection_request_features
src/xmpp/session.c: void session_login_success(gboolean)
src/xmpp/connection.c: void connection_request_features(void)

Here we are going for disco items discovery
iq_disco_info_request_onconnect(conn.domain)

When we received the features, we call 
src/xmpp/connection.c: void connection_features_received(const char* const)

There is a check:

if (
  g_hash_table_remove(conn.requested_features, jid) && 
  g_hash_table_size(conn.requested_features) == 0
)

if true, we call sv_ev_connection_features_received and than
omemo_publish_crypto_materials.

This function will add the _handle_own_device_list and request own
omemo bundles.

# Why do we need the disco? 

We are looking for the feature pubsub#publish-options
connection_supports(XMPP_FEATURE_PUBSUB_PUBLISH_OPTIONS

# What's the problem?

I saw some cases where we didn't call
"omemo_publish_crypto_materials". For instance, there was one person
with a IRC gateway. The IRC Gateway did not response to the disco iq
and we never got size = 0 if the hash map. There was also a second
case with wrong server config.

Unfortunately it *not* the same case in #1595 - we still need to
investigate.

# Solution?

Anyway, I'm wondering if it's a good idea to wait for "all" disco items
to setup OMEMO. My idea would be to wait for the "account domain" and
starte the OMEMO independently from other disco items (upload, muc.
irc,..)

See example in the patch file.

What do you think?

Attached patch:

From 43cbd927253838e0e95a109a766b71d865e93ced Mon Sep 17 00:00:00 2001
From: DebXWoody <stefan@debxwoody.de>
Date: Sun, 12 Sep 2021 11:15:33 +0200
Subject: [PATCH] Try to fix OMEMO / Disco issue

---
 src/omemo/omemo.c     | 8 +++++---
 src/xmpp/connection.c | 3 ++-
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/src/omemo/omemo.c b/src/omemo/omemo.c
index 952fea89..356c2d92 100644
--- a/src/omemo/omemo.c
+++ b/src/omemo/omemo.c
@@ -388,10 +388,12 @@ omemo_publish_crypto_materials(void)
 
     /* Ensure we get our current device list, and it gets updated with our
      * device_id */
-    g_hash_table_insert(omemo_ctx.device_list_handler, strdup(barejid), _handle_own_device_list);
-    omemo_devicelist_request(barejid);
 
-    omemo_bundle_publish(true);
+    if(g_hash_table_lookup(omemo_ctx.device_list_handler, strdup(barejid)) == NULL ) {
+        g_hash_table_insert(omemo_ctx.device_list_handler, strdup(barejid), _handle_own_device_list);
+        omemo_devicelist_request(barejid);
+        omemo_bundle_publish(true);
+    }
 
     free(barejid);
 }
diff --git a/src/xmpp/connection.c b/src/xmpp/connection.c
index e25b8f6f..10796d20 100644
--- a/src/xmpp/connection.c
+++ b/src/xmpp/connection.c
@@ -468,7 +468,8 @@ void
 connection_features_received(const char* const jid)
 {
     log_info("[CONNECTION] connection_features_received %s", jid);
-    if (g_hash_table_remove(conn.requested_features, jid) && g_hash_table_size(conn.requested_features) == 0) {
+    if(g_strcmp0(conn.domain, jid) == 0) {
+        log_info("[CONNECTION] Publish OMEMO %s", jid);
         sv_ev_connection_features_received();
     }
 }
-- 
2.30.2

jubalh · 2021-09-13T08:37:41Z

@daeluk if you apply that patch. Does the problem go away for you? Tell us if you need help with applying the patch.

jubalh · 2021-09-13T08:46:12Z

Just got a PM that the patch didn't help to solve @daeluk problem.

Messages would get duplicated when you chat with yourself, worse if you had omemo enabled the duplicated message would say something along the lines of "Your client doesn't support OMEMO". The cause was carbons when the message was sent from another client, whilst it was a sent and received message when profanity was the one to send it. This commit ignores the carbon message in the 1st case and ignores the received one in the 2nd. Fixes profanity-im#1595

jubalh · 2022-05-30T18:12:32Z

BTW did you trust your own keys?

MarcoPolo-PasTonMolo · 2022-05-30T18:17:45Z

In my case yes all keys are trusted and the issue persisted

Messages would get duplicated when you chat with yourself, worse if you had omemo enabled the duplicated message would say something along the lines of "Your client doesn't support OMEMO". The cause was carbons when the message was sent from another client, whilst it was a sent and received message when profanity was the one to send it. This commit ignores the carbon message in the 1st case and ignores the received one in the 2nd. Fixes profanity-im#1595

daakuser · 2023-10-15T15:08:45Z

Hi Experts,

Reaching out to all with an urgent help.
We are experiencing below error for quite sometime now while sending messages to some of the iOS and android clients.

Below is the detailed error -

I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on
https://conversations.im/omemo<markable
xmlns="urn:xmpp:chat-markers:0"><message_type xmlns="jabber:message:type">0</message_type>

Could anyone help us with the information on how we should get this working?

Thanks

jubalh · 2023-10-15T17:59:54Z

The message is quite self explanatory isnt it? The client doesn't support OMEMO.

Also when you have bugs you should mention each client names and versions.

sandeepjangir · 2023-10-16T09:05:32Z

Message sender's XMPP message packet:

<message type="chat" to="4f1b2d35-ece6-4c10-91a3-b14bb6242e12@xmpp.mydomain.co.in" id="56F26079-AEB3-4E20-942B-50C488AAA8ED"><store xmlns="urn:xmpp:hints"></store><encrypted xmlns="eu.siacs.conversations.axolotl"><header sid="1594171994"><key rid="421951349">MwohBSE7YJKmO6AcpcoOasiLBr89zBPrlqZ28MGeMnwttgwuEAYYCSIwlBf9zaZTLL0X4fZfysLTS+1nYsfcQ9eLL0oXvxvdqN9bRc0S8R5VuJH19MAAZ1OmQGH64XAQeM8=</key><iv>zNEQ2KVoMauAR0xooZpwhw==</iv></header><payload>XLbFfUu32TLGOgzVMuig9eOWmXbiX6Ag+g==</payload></encrypted><body>I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo</body><markable xmlns="urn:xmpp:chat-markers:0"></markable><message_type xmlns="jabber:message:type">0</message_type><Caption></Caption><request xmlns="urn:xmpp:receipts"></request></message>

Same Packet return back to sender:

<message xmlns="jabber:client" from="4f1b2d35-ece6-4c10-91a3-b14bb6242e12@xmpp.mydomain.co.in" to="2d7290eb-bb58-47fe-b4bb-c64658cc046c@xmpp.mydomain.co.in/537499" type="error" id="56F26079-AEB3-4E20-942B-50C488AAA8ED"><store xmlns="urn:xmpp:hints"></store><encrypted xmlns="eu.siacs.conversations.axolotl"><header sid="1594171994"><key rid="421951349">MwohBSE7YJKmO6AcpcoOasiLBr89zBPrlqZ28MGeMnwttgwuEAYYCSIwlBf9zaZTLL0X4fZfysLTS+1nYsfcQ9eLL0oXvxvdqN9bRc0S8R5VuJH19MAAZ1OmQGH64XAQeM8=</key><iv>zNEQ2KVoMauAR0xooZpwhw==</iv></header><payload>XLbFfUu32TLGOgzVMuig9eOWmXbiX6Ag+g==</payload></encrypted><body>I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo</body><markable xmlns="urn:xmpp:chat-markers:0"></markable><message_type xmlns="jabber:message:type">0</message_type><Caption></Caption><request xmlns="urn:xmpp:receipts"></request><error code="406" type="cancel"><blocked xmlns="urn:xmpp:blocking:errors"></blocked><not-acceptable xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"></not-acceptable></error></message>

jubalh · 2023-10-16T11:33:26Z

So first of all please open new bug since this is not related to this existing bug. And provide there all the information that is being asked for.

jubalh added the OMEMO label Sep 3, 2021

dontlaugh mentioned this issue Mar 29, 2022

OMEMO encryption failures #1615

Open

MarcoPolo-PasTonMolo mentioned this issue May 29, 2022

Fix duplicate messages in chat with oneself. #1717

Merged

jubalh closed this as completed in #1717 Jun 11, 2022

jubalh added this to the 0.13.0 milestone Jun 11, 2022

jubalh assigned MarcoPolo-PasTonMolo Jun 11, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OMEMO - Sending messages to myself, 'OMEMO not supported' #1595

OMEMO - Sending messages to myself, 'OMEMO not supported' #1595

daeluk commented Sep 2, 2021

jubalh commented Sep 3, 2021

daeluk commented Sep 4, 2021

jubalh commented Sep 5, 2021

daeluk commented Sep 5, 2021

daeluk commented Sep 5, 2021

paulfariello commented Sep 5, 2021

jubalh commented Sep 5, 2021

paulfariello commented Sep 6, 2021

jubalh commented Sep 6, 2021

daeluk commented Sep 8, 2021 •

edited

Loading

jubalh commented Sep 9, 2021

jubalh commented Sep 9, 2021

paulfariello commented Sep 9, 2021

jubalh commented Sep 9, 2021

daeluk commented Sep 11, 2021

DebXWoody commented Sep 11, 2021 via email

DebXWoody commented Sep 12, 2021 via email

jubalh commented Sep 13, 2021

jubalh commented Sep 13, 2021

jubalh commented Sep 13, 2021

jubalh commented May 30, 2022

MarcoPolo-PasTonMolo commented May 30, 2022

daakuser commented Oct 15, 2023

jubalh commented Oct 15, 2023

sandeepjangir commented Oct 16, 2023

jubalh commented Oct 16, 2023

OMEMO - Sending messages to myself, 'OMEMO not supported' #1595

OMEMO - Sending messages to myself, 'OMEMO not supported' #1595

Comments

daeluk commented Sep 2, 2021

Expected Behavior

Current Behavior

Steps to Reproduce (for bugs)

Context

Environment

jubalh commented Sep 3, 2021

daeluk commented Sep 4, 2021

jubalh commented Sep 5, 2021

daeluk commented Sep 5, 2021

daeluk commented Sep 5, 2021

paulfariello commented Sep 5, 2021

jubalh commented Sep 5, 2021

paulfariello commented Sep 6, 2021

jubalh commented Sep 6, 2021

daeluk commented Sep 8, 2021 • edited Loading

jubalh commented Sep 9, 2021

jubalh commented Sep 9, 2021

paulfariello commented Sep 9, 2021

jubalh commented Sep 9, 2021

daeluk commented Sep 11, 2021

DebXWoody commented Sep 11, 2021 via email

DebXWoody commented Sep 12, 2021 via email

jubalh commented Sep 13, 2021

jubalh commented Sep 13, 2021

jubalh commented Sep 13, 2021

jubalh commented May 30, 2022

MarcoPolo-PasTonMolo commented May 30, 2022

daakuser commented Oct 15, 2023

jubalh commented Oct 15, 2023

sandeepjangir commented Oct 16, 2023

jubalh commented Oct 16, 2023

daeluk commented Sep 8, 2021 •

edited

Loading