Let Bob broadcast/confirm his joining of a chat to all members

[hpk42]

Current: When Alice adds Bob back to a group, the others will only get green-checkmarked direct chats with Bob if Bob sends a message. Many 1:1 chats with Bob will be "broken".

Proposed: After a QR-code scan Bob should confirm his joining to a group to everyone so that all members learn and accept Alice's introduced Bob verified key as primary (which means all group members are now green with Bob in their direct chats).

Implementation: Currently, the "member-added-confirmed" message is only sent to Alice and in https://github.com/deltachat/deltachat-core-rust/issues/4914 we are discussing removing this code path. But that discussion started before we merged https://github.com/deltachat/deltachat-core-rust/pull/4898 three days ago, which opens up the opportunity to automatically fix verified bob keys for everyone through a single QR-scan from Bob on an Alice-group-invite code.

[iequidoo]

I think it's not possible to fix automatically in all cases. If i verified Bob in person, but then some Alice (even if we have groups in common) changes Bob's key for me w/o any acceptance on my side, it opens a security hole. Maybe if we see that the gossiped key is newer than the primary one, we should ask a user what to do, but not more. But if Alice was a verifier of Bob for me, then the primary key can be updated.

UPD: Also i don't quite understand what is the idea to send the "member-added-received" message to all members. Do we protect this way from Alice gossiping a wrong/stale Bob's key unintentionally? Because we can't protect from malicious Alice this way if they forge Bob's "From" or hacked Bob's server. But if it's just a protection from slowpoke Alice and useful only for those who learned Bob's key from Alice, is it a good reason to complicate the protocol?

[hpk42]

I think it's not possible to fix automatically in all cases. If i verified Bob in person, but then some Alice (even if we have groups in common) changes Bob's key for me w/o any acceptance on my side, it opens a security hole.

I don't see your comment as referring to the issue at hand. There is no claim to "fix automatically in all cases", and there is no "some Alice". The issue is about the UI feature of everyone in a group having green-checkmarked chats with Bob after Bob was re-scanned and joined into a group from a single Alice. All group members will then stop gossipping old Bob-keys afterwards, also in other groups. Letting Bob send member-added-confirmed to all group members does not change anything security-wise, and it is privacy-preserving.

[iequidoo]

By "some Alice" i meant that Alice could be someone i don't even know in person, but Bob could be my friend whose key i verified yesterday. So, a verification doesn't imply a trust. If Alice changes Bob's key for me in some group, my trust of Alice in doing so should be limited to groups with Alice (and even this is debatable) + to my contacts verified by/via Alice. My 1:1 chat with Bob is not a group with Alice and can't be fixed automatically.

The issue is about the UI feature of everyone in a group having green-checkmarked chats with Bob after Bob was re-scanned and joined into a group from a single Alice.

So, my objection to this is in regards to the word "everyone". Only those who learned Bob's key from Alice previously (directly or indirectly).

All group members will then stop gossipping old Bob-keys afterwards, also in other groups.

Here i agree in general. But "also in other groups with Alice".

Letting Bob send member-added-confirmed to all group members does not change anything security-wise, and it is privacy-preserving.

Also agree. But i'm just asking whether it's a good reason to complicate the protocol, considering concerns i pointed to.