search

deltachat / deltachat-core-rust

Delta Chat Rust Core library, used by Android/iOS/desktop apps, bindings and bots 📧
https://delta.chat/en/contribute
Other
664 stars 85 forks source link

Verified Group-addition fails on second device #3836

Closed hpk42 closed 1 year ago

hpk42 commented 1 year ago

Using Desktop master from today, and Android 1.34.5, there is this bug:

both desktop and android have bcc-self (copy to server) enabled of course.

gerryfrancis commented 1 year ago

@hpk42 I think this is caused when new messages are not received (downloaded) in chronological order. Secure join needs two emails (from Bob to Alice, and from Alice to Bob) to succeed, right? What if they were processed in the wrong order?

hpk42 commented 1 year ago

On Tue, Dec 13, 2022 at 00:36 -0800, gerryfrancis wrote:

@hpk42 I think this is caused when new messages are not received (downloaded) in chronological order. Secure join needs two emails (from Bob to Alice, and from Alice to Bob) to succeed, right? What If they were processed in the wrong order?

Here is a diagram with the flow of mails between Alice and Bob for "setup-contact": 

https://countermitm.readthedocs.io/en/latest/new.html#setup-contact-protocol

It's up to five e-mails flowing. I don't think it's ordering-related or related to concurrency around this.

The second device can ignore the chit-chat of the protocol but it eventually sees a "member added" message from its first device. And it fails to also add the member. The first device does it and all other chat members also did it. Just the second device fails to do it.

iequidoo commented 1 year ago

Looks like it is reproduced even with 1-1 verified group chat:

========== ac1_offl: going online, receiving message ==========                                                                                                                                                      
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/context.rs:382: starting IO
124.61 [events-ac3] DC_EVENT_CONNECTIVITY_CHANGED data1=0 data2=0
124.61 [events-ac3] DC_EVENT_CONNECTIVITY_CHANGED data1=0 data2=0
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/scheduler.rs:96: starting inbox loop
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/job.rs:353: loading job
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/scheduler.rs:355: starting smtp loop
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/scheduler.rs:548: scheduler is running
124.61 [events-ac3] DC_EVENT_CONNECTIVITY_CHANGED data1=0 data2=0
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/ephemeral.rs:549: Ephemeral loop waiting for deletion in 24h 0m 0s or interrupt
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/contact.rs:1545: Recently seen loop waiting for 24h 0m 0s or interrupt
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/smtp.rs:626: Sending MDNs
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/scheduler.rs:394: smtp fake idle - started
124.61 [events-ac3] DC_EVENT_CONNECTIVITY_CHANGED data1=0 data2=0
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/scheduler.rs:416: smtp has no messages to retry, waiting for interrupt
124.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/location.rs:653: Location loop is waiting for 24h 0m 0s or interrupt
127.03 [events-ac3] DC_EVENT_IMAP_CONNECTED data1=0 data2=IMAP-LOGIN as testg5eff@x.testrun.org
128.16 [events-ac3] DC_EVENT_INFO data1=0 data2=src/contact.rs:642: added contact id=10 addr=testkxjxu@x.testrun.org
128.16 [events-ac3] DC_EVENT_CONNECTIVITY_CHANGED data1=0 data2=0
128.16 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap.rs:1288: Starting a full FETCH of message set "2:4".
128.67 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap.rs:1406: Passing message UID 2 to receive_imf().
128.67 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:95: Receiving message, seen=false...
128.68 [events-ac3] DC_EVENT_INFO data1=0 data2=src/decrypt.rs:39: Detected Autocrypt-mime message
128.68 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/mimeparser.rs:758: Ignoring nested protected headers
128.68 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:138: received message has Message-Id: Mr.O83YZvPX8XE._irSQguSTeV@x.testrun.org
128.68 [events-ac3] DC_EVENT_INFO data1=0 data2=src/securejoin.rs:290: >>>>>>>>>>>>>>>>>>>>>>>>> secure-join message 'vg-request-with-auth' received
128.68 [events-ac3] DC_EVENT_INFO data1=0 data2=src/securejoin.rs:389: Fingerprint verified.
128.68 [events-ac3] DC_EVENT_MSGS_CHANGED data1=12 data2=12
128.68 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/securejoin.rs:647: StockMessage::ContactNotVerified posted to 1:1 chat (Auth invalid.)
128.68 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:1221: Message has 1 parts and is assigned to chat #Chat#Trash.
-------------------------------------------------------------------------------------------- Captured stdout teardown --------------------------------------------------------------------------------------------
129.18 [events-ac3] DC_EVENT_INFO data1=0 data2=src/contact.rs:1545: Recently seen loop waiting for 0h 9m 40s or interrupt
129.18 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap.rs:1406: Passing message UID 3 to receive_imf().
129.18 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:95: Receiving message, seen=false...
129.57 [events-ac3] DC_EVENT_INFO data1=0 data2=src/decrypt.rs:39: Detected Autocrypt-mime message
129.57 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/mimeparser.rs:758: Ignoring nested protected headers
129.57 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:138: received message has Message-Id: Mr.moFoM7BhGdI.qUhPQLVIeyG@x.testrun.org
129.57 [events-ac3] DC_EVENT_INFO data1=0 data2=src/securejoin.rs:290: >>>>>>>>>>>>>>>>>>>>>>>>> secure-join message 'vg-member-added-received' received
129.57 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/securejoin.rs:502: vg-member-added-received invalid.
129.57 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:1221: Message has 1 parts and is assigned to chat #Chat#Trash.
129.58 [events-ac3] DC_EVENT_INFO data1=0 data2=src/contact.rs:1545: Recently seen loop waiting for 0h 9m 40s or interrupt
129.58 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap.rs:1406: Passing message UID 4 to receive_imf().
129.58 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:95: Receiving message, seen=false...
129.59 [events-ac3] DC_EVENT_INFO data1=0 data2=src/decrypt.rs:39: Detected Autocrypt-mime message
129.59 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/mimeparser.rs:758: Ignoring nested protected headers
129.59 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:138: received message has Message-Id: Gr.0Mq0JH-9OaS.g3uDUjcac4c@x.testrun.org
129.59 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/receive_imf.rs:1490: verification problem: Sender of this message is not verified: testkxjxu@x.testrun.org
129.59 [events-ac3] DC_EVENT_INFO data1=0 data2=src/chat.rs:283: Created group/mailinglist 'hello' grpid=0Mq0JH-9OaS as Chat#13
129.59 [events-ac3] DC_EVENT_CHAT_MODIFIED data1=13 data2=0
129.60 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/receive_imf.rs:1688: verification problem: Sender of this message is not verified: testkxjxu@x.testrun.org
129.60 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/receive_imf.rs:978: verification problem: Sender of this message is not verified: testkxjxu@x.testrun.org
129.60 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:1221: Message has 1 parts and is assigned to chat #Chat#13.
129.60 [events-ac3] DC_EVENT_INFO data1=0 data2=src/contact.rs:1545: Recently seen loop waiting for 0h 9m 40s or interrupt
129.61 [events-ac3] DC_EVENT_INCOMING_MSG data1=13 data2=15
129.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap.rs:1445: Successfully received 3 UIDs.
129.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap.rs:811: 3 mails read from "INBOX".
129.61 [events-ac3] DC_EVENT_INCOMING_MSG_BUNCH data1=0 data2=0
130.11 [events-ac3] DC_EVENT_CONNECTIVITY_CHANGED data1=0 data2=0
130.11 [events-ac3] DC_EVENT_INFO data1=0 data2=src/scheduler.rs:289: IMAP session supports IDLE, using it.
130.62 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap/idle.rs:59: INBOX: Idle entering wait-on-remote state
132.77 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap/idle.rs:74: INBOX: Idle has NewData ResponseData { raw: 4096, response: Fetch(1, [ModSeq(8), Flags(["\\Seen"])]) }
133.28 [events-ac3] DC_EVENT_INFO data1=0 data2=src/job.rs:353: loading job
133.69 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap.rs:811: 0 mails read from "INBOX".
133.69 [events-ac3] DC_EVENT_INCOMING_MSG_BUNCH data1=0 data2=0
134.11 [events-ac3] DC_EVENT_MSGS_NOTICED data1=13 data2=0
134.11 [events-ac3] DC_EVENT_CONNECTIVITY_CHANGED data1=0 data2=0
134.11 [events-ac3] DC_EVENT_INFO data1=0 data2=src/scheduler.rs:289: IMAP session supports IDLE, using it.
134.11 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap.rs:1675: ignoring unsolicited response Other(ResponseData { raw: 4096, response: Fetch(2, [ModSeq(9), Flags(["\\Seen"])]) })
134.61 [events-ac3] DC_EVENT_INFO data1=0 data2=src/imap/idle.rs:59: INBOX: Idle entering wait-on-remote state

So, i think to continue the investigation with this simpler scenario. If i'm wrong, let me know

iequidoo commented 1 year ago

The reason is that vg-member-added message isn't received by the second device.

Btw, can somebody explain the purpose of vg-member-added-received/vc-contact-confirm-received messages in the protocol? They look excessive and for me it's like a try to solve that problem with two friends that want to meet and drink some beer but only if each of them is sure that their beermate is also going to the meeting :) Even if Bob didn't receive vg-member-added message (e.g. because of mail delivery problems), we can consider Bob joined -- Bob can try sending messages to the group and that must work afaiu. @r10s @flub @link2xt

iequidoo commented 1 year ago

The reason is that vg-member-added message isn't received by the second device.

Damn, it's because i forgot to enable bcc_self. But now i enabled it and see

128.51 [events-ac3] DC_EVENT_INFO data1=0 data2=src/mimeparser.rs:247: decrypted message mime-body:
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=no;
        protected-headers="v1";
Subject: hello
Chat-Verified: 1
Chat-Group-ID: UycOrbdb4lM
Chat-Group-Name: =?utf-8?q?hello?=
Chat-Group-Member-Added: tesths22n@x.testrun.org
Secure-Join: vg-member-added
From: <test8wu9r@x.testrun.org>

You added member tesths22n@x.testrun.org.

128.51 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/mimeparser.rs:757: Ignoring nested protected headers
128.51 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:137: received message has Message-Id: Gr.UycOrbdb4lM.27ARfZt8m5E@x.testrun.org
128.51 [events-ac3] DC_EVENT_INFO data1=0 data2=src/securejoin.rs:561: observing secure-join message 'vg-member-added'
128.51 [events-ac3] DC_EVENT_MSGS_CHANGED data1=12 data2=15
128.51 [events-ac3] DC_EVENT_WARNING data1=0 data2=src/securejoin.rs:647: StockMessage::ContactNotVerified posted to 1:1 chat (Fingerprint not provided, please update Delta Chat on all your devices.)

Looks like a new member's fingerprint should be added to vg-member-added message

flub commented 1 year ago

The reason is that vg-member-added message isn't received by the second device.

Btw, can somebody explain the purpose of vg-member-added-received/vc-contact-confirm-received messages in the protocol? They look excessive and for me it's like a try to solve that problem with two friends that want to meet and drink some beer but only if each of them is sure that their beermate is also going to the meeting :) Even if Bob didn't receive vg-member-added message (e.g. because of mail delivery problems), we can consider Bob joined -- Bob can try sending messages to the group and that must work afaiu. @r10s @flub @link2xt

Yes, this is a weird state. It is currently the difference between an internal state "un-idirectional verified" and the exposed state "bi-directional verified". The latter (bi-) means both know that both have each other verified, in the former (uni-) only one of them knows this and the other hasn't figured this out yet.

IIRC the last time this was discussed the revelation (at least to me) was that the main practical difference between these two is that bi-directional allows you to add the other person to a verified group, while if you only have them uni-directional verified you can not do they since they don't trust you enough (IIRC, there should be a cryptpad somewhere with this written down).

flub commented 1 year ago

Looks like a new member's fingerprint should be added to vg-member-added message

It should already be somehow, maybe via the gossip headers? Because you can introduce new members to a verified group and it transitively makes them verified to all group members.

link2xt commented 1 year ago

IIRC the last time this was discussed the revelation (at least to me) was that the main practical difference between these two is that bi-directional allows you to add the other person to a verified group, while if you only have them uni-directional verified you can not do they since they don't trust you enough (IIRC, there should be a cryptpad somewhere with this written down).

When Bob receives vc-auth-required, he already has Alice one-way verified. When Alice receives vc-request-with-auth, she has Bob two-way verified (she has verified Bob's key and she know Bob has verified her), but Bob still does not know about this. When Bob receives vc-contact-confirm (or vg-member-added) he sets Alice state to "two-way verified".

The question is what happens if vc-contact-confirm/vg-member-added is lost. In this case Alice has Bob two-way verified, while Bob has Alice only one-way verified. Because of this, Bob cannot safely add Alice to any verified group, because Bob thinks maybe Alice has not received vc-request-with-auth and has Bob completely unverified. However, Alice still can add Bob to verified groups and if Bob later receives any message from Alice in a verified group, he sets Alice to two-way verified, so eventually both Alice and Bob converge to a two-way verified state. This is not how it is currently implemented, but this was the idea during the discussion with @flub and @missytake.

But vg-member-added-received/vc-contact-confirm-received is an overkill and can be removed IMO, it does not solve any problem.

iequidoo commented 1 year ago

Ok, will remove vg-member-added-received/vc-contact-confirm-received after fixing the bug.

It should already be somehow, maybe via the gossip headers? Because you can introduce new members to a verified group and it transitively makes them verified to all group members.

But now the code is written so that it expects the newly added member's fingerprint in vg-member-added message and i already tried adding it and this fixes the bug. So, i suggest to fix the code as it's supposed to work and then maybe make design improvements. At the moment there are no gossip headers (at least i don't see in the logs) in the Securejoin proto

link2xt commented 1 year ago

Alice broadcasts an encrypted “vg-member-setup” message to all members of GROUP (including Bob), gossiping the Autocrypt keys of all members (including Bob). (https://countermitm.readthedocs.io/en/latest/new.html#joining-a-verified-group-secure-join, there vg-member-added is named vg-member-setup).

So gossip should be in the vg-member-added message, if it's not, it's the bug.

iequidoo commented 1 year ago

Alice broadcasts an encrypted “vg-member-setup” message to all members of GROUP (including Bob), gossiping the Autocrypt keys of all members (including Bob). (https://countermitm.readthedocs.io/en/latest/new.html#joining-a-verified-group-secure-join, there vg-member-added is named vg-member-setup).

So gossip should be in the vg-member-added message, if it's not, it's the bug.

Added logging of messages, but see no gossips at all:

121.59 [events-ac3] DC_EVENT_INFO data1=0 data2=src/receive_imf.rs:98: receive_imf: incoming message mime-body:
Return-Path: <test5y44z@x.testrun.org>
Received: from dc.develcow.de ([172.22.1.253])
        by 543abdb98f5e with LMTP
        id CG6VF+5MsmNhbCoAQ3Ur8g
        (envelope-from <test5y44z@x.testrun.org>); Mon, 02 Jan 2023 04:18:06 +0100
Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id E48D133BE4F;
        Mon,  2 Jan 2023 04:18:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=x.testrun.org;
        s=dkim; t=1672629485;
        h=from:subject:date:message-id:to:mime-version:content-type:references:autocrypt;
        bh=EyllUtfep6cIigsTo15dLs2cm/NSGR3EI98rIU021EI=;
        b=I2hPgpNUo2nzUn4s4DD6R0qCQVZOEzN0bIi1IbGZ6Sb9Q0sjIJmFftIcs+XTGzfVeYpRQZ
        vSZKGVd4Pj/0/tUgdgRn30/g1czi8isE/0Pca0ja388yfM+HWrQr3yAz6WSlp/Ync9cWQ4
        idZ4k5EnUbFFYI6rJkCLNq9JiPiiM7d2965k97Bmn9ZiJfMfMjv19q3CDcRpw6weNODbth
        CcgjQdj9cZxGLVUOvPo1CtZxfFEesa/juXn4hqIgPlyaDAKBnwSuj165+khMNCj7p6PQQi
        4mgQuWZJnmjuHkpXKJXygBHjN41RwddVZ908Z7vG6DiF9kVXFTvWZ4klTBOVHw==
Subject: ...
From: <test5y44z@x.testrun.org>
To: <testtp73j@x.testrun.org>
Date: Mon, 02 Jan 2023 03:18:04 +0000
Message-ID: <Gr.IHjl00P2Ggv.nBjK2XPLxY-@x.testrun.org>
References: <Gr.IHjl00P2Ggv.nBjK2XPLxY-@x.testrun.org>
Chat-Version: 1.0
Autocrypt: addr=test5y44z@x.testrun.org; prefer-encrypt=mutual;
        keydata=mDMEXlh13RYJKwYBBAHaRw8BAQdAzfVIAleCXMJrq8VeLlEVof6ITCviMktKjmcBKAu4m5
        C0GUFsaWNlIDxhbGljZUBleGFtcGxlLm9yZz6IkAQTFggAOBYhBC5vossjtTLXKGNLWGSwj2Gp7ZRD
        BQJeWHXdAhsDBQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEGSwj2Gp7ZRDE3oA/i4MCyDMTsjWqD
        ZoQwX/A/GoTO2/V0wKPhjJJy/8m2pMAPkBjOnGOtx2SZpQvJGTa9h804RY6iDrRuI8A/8tEEXAA7g4
        BF5Ydd0SCisGAQQBl1UBBQEBB0AG7cjWy2SFAU8KnltlubVW67rFiyfp01JrRe6Xqy22HQMBCAeIeA
        QYFggAIBYhBC5vossjtTLXKGNLWGSwj2Gp7ZRDBQJeWHXdAhsMAAoJEGSwj2Gp7ZRDLo8BAObE8Gns
        GVwKzNqCvHeWgJsqhjS3C6gvSlV3tEm9XmF6AQDXucIyVfoBwoyMh2h6cSn/ATn5QJb35pgo+ivp3j
        sMAg==
MIME-Version: 1.0
Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
        boundary="p5uy1a5CtaOO96fHPDoY8R4jPCUwzf"
X-Last-TLS-Session-Version: TLSv1.3

--p5uy1a5CtaOO96fHPDoY8R4jPCUwzf
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

--p5uy1a5CtaOO96fHPDoY8R4jPCUwzf
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc";

-----BEGIN PGP MESSAGE-----

wcBMA+PY3JvEjuMiAQf/Tn/THcK5jruFSmxoos78LRH20GrDBMS+WSOo05mg340j
wz8fxsYM2haCHwVw5JUj4UP1P5TRu6gu5JZbhxpqWv3PAYt5N7eH7EO5tnre1LvK
YqBC/2iNVoIP8+MOIADdrfd3sGcshI3ODIplM1X0joaLxAicNE58jxdU/tbslazf
+ZpD2prz2T7IQyyFfTGtvtC3cQodl/0d4brmazwl2ABySebm0dySn0gobsDvP8r9
omTfTEYLaAGto8RNtHqI0HsY4sr/V1iDazut8KNsMWiun2cZZqGX/koCp68i1eWo
ES8kzwcYIPfUGCxce2sDZk0Tc7xRxdvfm++Vk0UgmcFOA+baut4U3nmwEgEHQBQx
lKUSh2STiG+tSgCCXAPRQWl0CfSavoSp5ZWQQHwDIHNC5LbsGxN5E9WXP4PxQQfg
PFId/bkesARTi2T4JX1u0sFFAdPZB9BGK+wYAyefKzP2dc33bknoLEBgVcBDGK3Q
U1WfGEJdimolR9PSQ6gNF2AbDYgV6y0rI8ggJhrLrFi1gBTZfNiFMDSFDnYfJNaw
Sfn39JARTpSVhYqX7MrG0XdwHwtJd+jREDsfaj3/dRTZFMPtaBmfyWkmTM/WbxmS
zJObNwKkgqg6zpUQzth/Cqx3ZUjaiRyFzSw/wOkRy8nZzRKQcS62OiQ7XoUcGU28
ZestXXbMPoc7VXyOBkuu8lcve7GtHLByEzMPTVvZuuvFFIcX39USzFB1rHoueLhK
0g5yUzMNvFkaLwEV1E4j307ALquEiEeDv6a5EbRwMK1ssjAEq3+TCirezlK6RVjD
Mqv0tNYg6SwYXNmu5vt2NszyholIYt/X4vFA4yW9fFf8S0OHLugs9l7DoqhEgPlC
xyqmZmPCZKqXnNvGd3aaWG8C3FdOOYJYGRzaZsCw3o5x32nDsddCtzjRJVAuVryM
hpjhWfEVoq2/js+5kGFCJbjmG9qnx4EFfEeeQwpyA91XAFAXZCLErSEKHpe4HW3O
/gU2RVSvvJRWXciUtsOoNnkc3MpwoOBcD4O0eukVv66ioNEX0TvEG7zL2sMdfnYw
1B73nXzWdygTHLY7sLMHX83cnbdovTPkjWh8CK9DJQf+zW9UI7WKBoz26K33U6uo
cVdHd3gUpw==
=UEWe
-----END PGP MESSAGE-----

--p5uy1a5CtaOO96fHPDoY8R4jPCUwzf--

121.60 [events-ac3] DC_EVENT_INFO data1=0 data2=src/decrypt.rs:39: Detected Autocrypt-mime message
121.60 [events-ac3] DC_EVENT_INFO data1=0 data2=src/mimeparser.rs:247: decrypted message mime-body:
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=no;
        protected-headers="v1";
Subject: hello
Chat-Verified: 1
Chat-Group-ID: IHjl00P2Ggv
Chat-Group-Name: =?utf-8?q?hello?=
Chat-Group-Member-Added: testtp73j@x.testrun.org
Secure-Join-Fingerprint: CCCB5AA9F6E1141C943165F1DB18B18CBCF70487
Secure-Join: vg-member-added
From: <test5y44z@x.testrun.org>

You added member testtp73j@x.testrun.org.

Secure-Join-Fingerprint: CCCB5AA9F6E1141C943165F1DB18B18CBCF70487 is added by me here (and it helps). There's the code added by @r10s in 52442017e23da66837bc954842a1d516347e0af3 that expects it, but no explanation in the commit message why it's implemented this way. So, do you suggest to rework this as described in the spec instead of "hotfixing"?

iequidoo commented 1 year ago

I belive that gossips are better, yes, because this way we provide a public key (allowing others to encrypt), not a fingerprint only

iequidoo commented 1 year ago 
--- a/src/mimefactory.rs                                                                                                                                                                                             
+++ b/src/mimefactory.rs                                                                                                                                                                                             
@@ -689,7 +689,7 @@ pub async fn render(mut self, context: &Context) -> Result<RenderedEmail> {                                                                                                                      
                 .fold(message, |message, header| message.header(header));                                                                                                                                           

             // Add gossip headers in chats with multiple recipients                                                                                                                                                 
-            if peerstates.len() > 1 && self.should_do_gossip(context).await? {                                                                                                                                      
+            if (peerstates.len() > 1 || context.get_config_bool(Config::BccSelf).await?) && self.should_do_gossip(context).await? {                                                                                 
                 for peerstate in peerstates.iter().filter_map(|(state, _)| state.as_ref()) {                                                                                                                        
                     if peerstate.peek_key(min_verified).is_some() {                                                                                                                                                 
                         if let Some(header) = peerstate.render_gossip_header(min_verified) {

This fixes gossips for the scenario. Ok, let's implement it according to the spec

link2xt commented 1 year ago

Related PR: #3914

hpk42 commented 1 year ago

thanks!

On Thu, Jan 12, 2023 at 10:16 -0800, iequidoo wrote:

Closed #3836 as completed.

-- Reply to this email directly or view it on GitHub: https://github.com/deltachat/deltachat-core-rust/issues/3836#event-8214208302 You are receiving this because you were mentioned.

Message ID: @.***>

hpk42 commented 1 year ago

it does not seem to work really yet. Just joined a verified group on Android (1.34.10) -- and then on desktop (which is compiled from yesterday) i experienced this:

So it doesn't really work yet. Note, however, that this info i provide here is from the "getting-added side", not from the "invitation" side. still matches the issue title and is related but might be a separate issue coding-wise.

Screenshot from 2023-01-19 17-48-44

link2xt commented 1 year ago

Does the member added message contain gossip?

link2xt commented 1 year ago

It's a different situation. Here you are joining the group rather than adding a new verified member.

The fix #3914 is for the case when you add a member to verified group and your other device observes that you have added someone to the verified group.

In the still failing case Alice creates a group and gives Bob an invite QR code. Bob joins the group via the QR code. On the device which scans the code Bob gets the verified group, and Alice along with all group members are marked as verified. But on the second device of Bob group creator is not marked as verified, so Bob can't even send the message to leave the group from this device, as it cannot be properly encrypted with unknown Alice key.

iequidoo commented 1 year ago

I think this should be fixed by adding gossips also to "vg-request-with-auth"/"vc-request-with-auth" messages. Other Bob's devices may trust them thus learning Alice's key

link2xt commented 1 year ago

@iequidoo If there is no way to extract verified key fingerprint already (fingerprint of the key Bob's other device used to encrypt v*-request-with-auth to Alice), then adding a gossip of Alice's key (rather than fingerprint) is good enough.

iequidoo commented 1 year ago