"This message was sent with non-verified encryption. See 'Info' for more details."

[dkg]

On Desktop 1.46.1 (using .deb packages, on a debian trixie (testing) system), i received several messages in a group chat which read:

"This message was sent with non-verified encryption. See 'Info' for more details."

In the same group chat, on Android 1.46.7, i can read the actual contents of these messages.

I've upgraded Desktop to 1.46.5 (the latest downloadable from https://delta.chat/en/download) i still can't see the actual content from those messages.

Furthermore, there was no "Info" available in the per-message options on desktop 1.46.1 (there is one now, in 1.46.5).

When i look at "info" in Desktop 1.46.5 on the first such message, one of the header lines reads:

Error: Unknown Sender for this chat.  See 'info' for more details.

Note that this is a different error message than the one rendered outside of the "info" viewer.

None of the other messages in the chat that visibly say "sent with non-verified encryption" show any Error: pseudoheader when viewed with "info". But all such broken messages are either sent from the same sender, or are in reply to that sender.

I also note that Desktop 1.46.5 thinks this chat has 9 participants, while Android thinks it has 8 participants. (i don't know how many participants were listed in Desktop 1.46.1). The Desktop participant list is a strict superset of the Android user list. One of the participants in the chat had two different e-mail addresses involved, and has now simplified to only one of them. The new (and permanent) address for that participant is the sender of the first broken message. I'll check with the group to see whether they're ok with publishing screenshots.

[dkg]

hm, i can send messages to this group now from Android, but i cannot send from desktop. when i try to send from desktop i get a red ⓘ icon that, when clicked, reveals a message saying "Error: proper enc-key for [REDACTED_ADDRESS] missing, cannot encrypt".

However, when i send a message directly to the user at that address, the direct message goes through and claims it was encrypted. Confusing! Let me know if there's anything else i should do to debug, or what i need to do to get my Desktop installation properly synchronized.

[dkg]

a member of the group dropped me from the group and re-added me and now both devices work fine in the group (and both see 8 members, not 9). So i've worked around it, but i'm not entirely sure i understand what happened to cause the de-sync.

[dkg]

I'm happy to try to replicate the problem if anyone wants to do that. just let me know what you think reasonable next steps are.

[huitema]

There was an interesting change in membership in the chat that @dkg mentioned. I first joined that chat on my old laptop. When I replaced it, I had to use a different identity, and a different encryption key -- why I did not manage to do that may be a bug in itself. The old identity was removed from the chat. I think that the removal happened when @dkg was offline, and that when he reconnected from his desktop the chat history contained old messages with the old identity, messages that the desktop had not yet seen.

That would explain 9 members vs. 8: the extra member would be my old identity. That might also explain the encryption issues: messages from my old identity would still be in the chat log, but my old key has been removed and the messages cannot be read anymore.

At a minimum, that's a UI bug, because the manner in which these old messages were presented is confusing. It is clearly a bug in the desktop app, because the Android app was processing the chat as expected.

[link2xt]

I've upgraded Desktop to 1.46.5 (the latest downloadable from https://delta.chat/en/download) i still can't see the actual content from those messages.

Delta Chat processes messages only once, when they are downloaded. If there was an error at the time of the message download, it is not possible to recover from it later.

Furthermore, there was no "Info" available in the per-message options on desktop 1.46.1 (there is one now, in 1.46.5).

I think the option was there, just under a different name: deltachat/deltachat-desktop#3961

Note that this is a different error message than the one rendered outside of the "info" viewer.

I think we should stop replacing the text of unverified messages with an error in square brackets, it is a very hacky way to show errors.
This happens here:

deltachat-core-rust/src/receive_imf.rs

Line 1361 in c7c3b9c

mime_parser.replace_msg_by_error(&s);

We have previously got rid of another case of such replacing:
#5024

There is a dedicated issue about this hacky UI:
#4999

when i try to send from desktop i get a red ⓘ icon that, when clicked, reveals a message saying "Error: proper enc-key for [REDACTED_ADDRESS] missing, cannot encrypt"

I assume the group has a green checkmark. In this case sending to the user requires a "verified" key. Error means there is no "verified" key for this contact.

However, when i send a message directly to the user at that address, the direct message goes through and claims it was encrypted.

But 1:1 has no green checkmark?

a member of the group dropped me from the group and re-added me and now both devices work fine in the group (and both see 8 members, not 9). So i've worked around it, but i'm not entirely sure i understand what happened to cause the de-sync.

It seems desktop somehow did not mark the key as verified when observing securejoin or participating in it.

[link2xt]

That might also explain the encryption issues: messages from my old identity would still be in the chat log, but my old key has been removed and the messages cannot be read anymore.

All devices download and process messages in the same order, including membership changes messages. There can however be differences in the order of messages when one of your devices is sending messages, because they are added into the chat history of the sender before all other devices receive a message.

For example, when you remove someone from the group you may receive a message by them after removing them from the group because they have not received a message about being removed.

It is clearly a bug in the desktop app, because the Android app was processing the chat as expected.

Android and Desktop use the same core library, so it's more likely some sort of a bug that could have happened to Android instead.

[link2xt]

Let's discuss the UI of the error message in #4999 and limit this issue to figuring out why different devices using the same account can end up with different verification state.

@dkg Have you invited other members to join the group and sent the QR code or invite link to other members? Or you just observed other members joining the group (i.e. seeing the final "member added") message?

I suspect there can be tricky cases when the inviting party has multiple devices. Both devices try to reply to securejoin messages and some messages are deleted via IMAP after processing.

At the very least before closing the issue we need to add online test for securejoin with multiple inviter ("Alice") devices into https://github.com/deltachat/deltachat-core-rust/blob/main/deltachat-rpc-client/tests/test_securejoin.py and maybe offline test into https://github.com/deltachat/deltachat-core-rust/blob/main/src/securejoin.rs

[link2xt]

Made a fix: #5930

[link2xt]

I think the key problem is that user never wrote into the group after joining it via the QR code. In most cases users write something into the group right after joining and this way second device sets backward verification because now it knows that Bob (invited party) has Alice's key set as verified and can write into the group. This is why not everyone is affected by this bug and in most cases multi-device setup works.

[iequidoo]

I think the key problem is that user never wrote into the group after joining it via the QR code. In most cases users write something into the group right after joining and this way second device sets backward verification because now it knows that Bob (invited party) has Alice's key set as verified and can write into the group.

But why should the backward verification affect writing to the group for other Alice's devices? Having the Bob's key "forward-verified" is sufficient, i.e. it's safe to send messages to the group. I agree that the bug should be fixed, but then for Bob joining groups is not reliable, e.g. one of the Bob's devices may miss vg-member-added, but if the device has the Alice's key verified (and for other members as well) and sees any messages containing Bob in To:, it should be able to write to the group.

[link2xt]

Actually sending to the group does not require backward verification. Error: proper enc-key for [REDACTED_ADDRESS] missing, cannot encrypt means there was no forward key stored, don't know how this happened.