properly add a member triggered by unrelated secure-join protocol#4896
properly add a member triggered by unrelated secure-join protocol#4896
Conversation
hpk42
changed the title
hpk42
force-pushed
the
hpk/blobstate-fix-4894
branch
2 times, most recently
from
8784fb7 to
49de4fd
Compare
hpk42
force-pushed
the
hpk/blobstate-fix-4894
branch
from
49de4fd to
55b8a6c
Compare
| break | ||
|
|
||
| lp.sec("ac1: let ac2 join again but shutoff ac1 in the middle of securejoin") | ||
| ac2.qr_join_chat(ch1.get_join_qr()) |
There was a problem hiding this comment.
isn't easier if ac1 scans the QR of ac2 after ac2 is already shutdown/offline? that was the way we tested it IRL, and would avoid the need for the next loop below 🤔
There was a problem hiding this comment.
This is a workaround for a check that will be removed in a follow-up PR:
https://github.com/deltachat/deltachat-core-rust/blob/6aae0276da4c20736254055ee3941cac71292f6e/src/securejoin/bobstate.rs#L338-L367
It checks that Bob knows the group he is joining is verified. IRL we probably left the verified group and rejoined it, here we terminate once we learn it is verified instead of fully joining and then leaving and then starting a join again.
Hocuri
left a comment
Hocuri
left a comment
There was a problem hiding this comment.
The code change LGTM; I only skimmed over the test since it's getting late here
4 participants
Fixes #4894
so that a "left-over" bobstate does not block a receiver of a MemberAdded message from adding the member if it was added through an unrelated secure-join process (i.e. the receiver was not the member being added through the secure-join protocol)