-
-
Notifications
You must be signed in to change notification settings - Fork 104
Open
Labels
bugSomething is not workingSomething is not working
Description
when scanning a QR code, the chat does not allow to send messages, as they cannot be encrypted yet.
however, if the other side does not respond within 15 seconds (grep for SECUREJOIN_WAIT_TIMEOUT
), a message is added to the chat, saying that you can already send a message, even though e2ee is not established yet:

the reason for the timeout being introduced that time was to not let ppl send accidentally an unencrypted message (doing a qr code scan and sending the message a second before e2ee is established)
with chatmail, however, things have changed, as sending unencrypted messages is not possible at all.
possible fixes:
- as a quick-fix we could maybe tweak the wording (how?)
- probably better, remove the timeout at least for chatmail
- maybe remove the timeout alltogether, to not offer more "e2ee but" vectors - non-chatmail users can start a conversation also by entering the email address - and scanning a QR code would always result in e2ee
Metadata
Metadata
Assignees
Labels
bugSomething is not workingSomething is not working
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
Hocuri commentedon Mar 27, 2025
I'm in favor of fix 2. or 3.
Edit: I tend a bit towards fix 3, removing the timeout altogether. In DC-DC usage it's usually not useful because mostly, both sides will use Chatmail. In DC->Email usage it's not useful because there are no QR codes you can scan there. The only case where it's useful is when Alice uses DC with a classical account (or a self-hosted chatmail account where she is able to send messages), and Bob also uses DC, and the securejoin messages are delayed a lot or don't arrive at all (in which case the messaging experience isn't going to be great, anyway - and Alice is going to have a bad time when she notices that she can't add Bob to verified groups).
And getting rid of complexity is always great.
hpk42 commentedon Mar 28, 2025
link2xt commentedon Mar 30, 2025
If we remove timeout, users will still be able to send unencrypted message. For setup contact protocol (not joining the group), 1:1 chat is created immediately but is blocked for 15 seconds by
why_cant_send_ex
. If we simply remove the timeout-related code, thenwhy_cant_send_ex
will allow to send immediately. Do we just want to block the 1:1 chat forever somehow? Then showing a wrong QR code for email address to someone will block the chat with this email address forever because the email address have no key.r10s commentedon Mar 30, 2025
my idea is to
unconditionally block the chat until e2ee is established
after ~15 seconds, instead of letting can_write() return true, only add a message with further information ("NAME is not reachable. you can leave this chat now. e2ee will be established in background as soon as both devices are online.")
for the mentioned "forever blocking when showing wrong qr code for an address" (however this can happen):
shouldn't a new scan remove the old, blocked process?
so should the deletion of the chat
link2xt commentedon Mar 31, 2025
We have multiple Bob processes now and old processes are not removed if they still have a chance to finish. Starting a new process with a working QR code will result in encrypted chat.
The only problem is that if you don't have a working QR code (e.g. because the address does not use DC anymore) you can no longer send unencrypted message.
Receiving an unencrypted message from this address should fix the problem I think. On desktop we have a "reset encryption" button in the encryption info as well, it should help in resolving this if you really want to drop to unencrypted.
r10s commentedon Mar 31, 2025
i can confirm, this works as expected with the PR #6722 - if Bob scans a bad QR code of Alice, things are stuck, but when Bob scans later a working one, things are fine
so, this is a situation that is interesting only for non-chatmail, right?
you can also fix that by just deleting the chat and then creating a new one manually, you can then send unencrypted. as this seems to be a cornercase, it's probably good enough.
feat: no unencrypted chat when securejoin times out (chatmail#6722)
fix: Allow to send to chats after failed securejoin again (#6817)
Hocuri commentedon Apr 23, 2025
Reopening because #6817 reverted the fix
link2xt commentedon Apr 23, 2025
We should revert the revert from #6817 after PGP-contacts (#6796). It adds
is_encrypted()
which makes it possible to see that the chat is encrypted, then there is no need to ever block sending there. Worst case the message is not sent because you don't have keys.