Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

OMEMO encryption failures #1615

Open
mdosch opened this issue Nov 14, 2021 · 11 comments
Open

OMEMO encryption failures #1615

mdosch opened this issue Nov 14, 2021 · 11 comments
Labels
bug OMEMO

Comments

@mdosch
Copy link
Contributor

mdosch commented Nov 14, 2021

Profanity seems to often forget OMEMO fingerprints. Sometimes it just doesn't find OMEMO keys to encrypt to, even if messages were sent successfully just minutes ago.
In 1-1 I get a warning and can do the /omemo end + /omemo start cycle and send it again. In MUCs I get a warning about missing fingerprints but the message is sent anyway. So sometimes the particular MUC participant already complains about not being able to read the message before I finished the /omemo end + /omemo start + resend cycle.

Expected Behavior

Profanity should not forget contacts keys.

Current Behavior

Profanity forgets contacts keys.

Steps to Reproduce (for bugs)

Just use OMEMO in 1-1 and MUCs. I monitored this for a while but I found no way to reproduce it as it seems random.

Environment

  • Debian Testing (Bookworm
profanity -v
Profanity, version 0.12.0dev.master.9a9122c1
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: libstrophe
Desktop notification support: Enabled
OTR support: Enabled (libotr 4.1.1)
PGP support: Enabled (libgpgme 1.16.0-unknown)
OMEMO support: Enabled
C plugins: Enabled
Python plugins: Enabled (3.9.8)
GTK icons/clipboard: Disabled
@devhell
Copy link

devhell commented Jan 26, 2022

This happens to me too.

@dontlaugh
Copy link

dontlaugh commented Mar 27, 2022 •
edited

I often get this message in 1-1 chats where I have multiple, personal client involved (sometime two profanity clients, a Dino client, and a Monocles client)

You received a message encrypted with OMEMO but your client doesn't support OMEMO.

Is it related?

edit: #1595 actually seems closer to what I do

@jubalh
Copy link
Member

jubalh commented Jun 15, 2022

@sjaeckel recently told me he saw some strange stuff in our OMEMO implementation.

@sjaeckel Could these be caused by it?

@jubalh
Copy link
Member

jubalh commented Jun 15, 2022

@dontlaugh #1595 is fixed now btw.

@jubalh
Copy link
Member

jubalh commented Aug 3, 2022

@mdosch is this still happening?

@mdosch
Copy link
Contributor Author

mdosch commented Aug 3, 2022

Honestly, I avoided writing to OMEMO MUCs with profanity since it was annoying to instantly get a screenshot of "this message was not encrypted to your device" (common OMEMO key mess stuff, Ox FTW!) back whenever this happened before I was able to OMEMO-cycle and resend. If there were changes to OMEMO which could have fixed this I will try again.

@mdosch
Copy link
Contributor Author

mdosch commented Aug 3, 2022

Ok, just send an OMEMO message (in 1-1 which luckily doesn't go out if encryption fails) and had to do the OMEMO cycle again.

@jubalh
Copy link
Member

jubalh commented Aug 3, 2022

Thanks for checking

@TURING-V2
Copy link

any temp fix on this ? each time I login gets ,on read and unread msgs
You received a message encrypted with OMEMO but your client doesn't support OMEMO.
omemo fingerprint are trusted then why cant it decrypt.

@mdosch
Copy link
Contributor Author

mdosch commented May 6, 2023 via email

@mdosch
Copy link
Contributor Author

mdosch commented Oct 28, 2023 •
edited

Just accidentally wrote a message to an OMEMO MUC and forgot that there is a contact where profanity always failed to encrypt (usually I work around this issue by only using conversations for this MUC)…
I confirmed that the contacts OMEMO pep node and device list node are set to "open" and conversations also works, so it seems to be a profanity issue.
Maybe profanity could refuse to send the message as it does in 1-1 when it can't encrypt to workaround the annoying case of others complaining not being able to decrypt messages until the root cause is found?

Right now profanity just shows Can't find a OMEMO device id for REDACTED@diebesban.de. (two times, although I sent only one message) but sends the broken message (not encrypted for all MUC participants) anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug OMEMO
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@devhell @jubalh @mdosch @TURING-V2 @dontlaugh