Remove protected chats and expire auth tokens#7116
Conversation
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
from
c7e6f1c to
e180d7f
Compare
|
|
||
| -----BEGIN PGP MESSAGE----- | ||
|
|
||
| wU4D5tq63hTeebASAQdATHbs7R5uRADpjsyAvrozHqQ/9nSrspwbLN6XJKuR3xcg |
There was a problem hiding this comment.
Payload here is replaced to have no Chat-Verified header inside and have _verified=1 in gossip headers. Payload got larger likely because rsop does not do compression and I had to reencrypt the payload.
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
4 times, most recently
from
867c2ba to
780ca50
Compare
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
3 times, most recently
from
53d6a2d to
a6301b9
Compare
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
11 times, most recently
from
88700f4 to
5b31b5d
Compare
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
from
6b67844 to
6052d1a
Compare
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
from
6052d1a to
4e956bd
Compare
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
from
f1389dd to
701dafe
Compare
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
4 times, most recently
from
1e435ca to
66bffdb
Compare
| let chat = Chat::load_from_db(context, chat_id).await?; | ||
| if chat.is_encrypted(context).await? | ||
| && !chat.param.exists(Param::Devicetalk) | ||
| && !chat.param.exists(Param::Selftalk) |
There was a problem hiding this comment.
This is fine, but probably https://delta.chat/en/help#save should say that saved messages are encrypted (if they are sent of course, e.g. in a multi-device case)
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
from
66bffdb to
0f94529
Compare
|
This is blocked by not having a 2.13 release on all platforms. Android, iOS and Desktop are using core 2.11 currently, which means they don't support |
|
then I don't think the other PR should be blocked by this one, should just use main, if someone tried this PR with production device which they shouldn't they can restore from another device |
How much time are we going to wait so that most users get updated to 2.13? Or are we going to break verification through groups for not updated users? |
This mechanism replaces `Chat-Verified` header. New parameter `_verified=1` in `Autocrypt-Gossip` header marks that the sender has the gossiped key verified. Using `_verified=1` instead of `_verified` because it is less likely to cause troubles with existing Autocrypt header parsers. This is also how https://www.rfc-editor.org/rfc/rfc2045 defines parameter syntax.
Create unprotected group in test_create_protected_grp_multidev The test is renamed accordingly. SystemMessage::ChatE2ee is added in encrypted groups regardless of whether they are protected or not. Previously new encrypted unprotected groups had no message saying that messages are end-to-end encrypted at all.
5 participants
Since key-contacts cannot change their keys and having "verification" is less important for contact identification than having a chat history or shared chats with a contact, UIs have stopped displaying green checkmarks everywhere (deltachat/deltachat-android#3828).
This PR removes protected chats and replaces old mechanism of propagating verifications via protected chat messages marked with
Chat-Verified: 1header with a new_verifiedattribute ofAutocrypt-Gossipheaders.Receiving
_verifiedattribute inAutocrypt-Gossipis already supported in 2.13.0 release. This PR switches from usingChat-Verifiedheader toAutocrypt-Gossip.Closes #7080 (replace verification gossip mechanism with a new one that works using Autocrypt-Gossip header and is independent of "protected chats").
It also makes authentication tokens in QR codes expire and closes #7111
As a preparation for expiring QR codes it takes into account sync item timestamps (closes #7182) for QR code tokens, so synced QR code tokens have a timestamp of sync messages and when token removal is synchronized tokens newer than the sync item are not removed.
Also closes #7112 (removing deprecated and unneeded APIs)
Finally, this PR adds a migration that resets all indirect verifications. There was a bug #7107 (closed in #7113) that resulted in updating "verified by" information for already verified contacts, so the information about "verifiers" is lost and overwritten with incorrect indirect verifiers.
Expiring auth tokens also make new direct verifications more meaningful, but I have decided not to reset direct verifications as they are not affected by bugs that accidentally result in verifying someone directly. If the user did not publicly share the invite link, then verifications are valuable and resetting all of them will likely not be received well.
As we reset indirect verifications at the same time as we change the mechanism used to propagate verifications, old incorrect verifications will not propagate to new versions even though users do not upgrade at the same time.
We can also allow to remove verification from contacts (https://support.delta.chat/t/how-would-i-remove-the-verified-checkmarks-from-one-invite-code-in-retrospect/3403) as it will not break "protected" chats anymore, but this is out of scope for this PR.
What this PR does:
is_protection_brokenAPIs. (moved to Various protected group changes #7146)is_profile_verifiedAPI. (moved to Various protected group changes #7146)Chat-Verified: 1header._verifiedattribute forAutocrypt-Gossipand use it to indirectly verify key-contacts when such attribute is received from a verified contact (whether directly verified or not).add_partsthat result in "The message was sent by non-verified contact" messages. We likely don't need to passverified_encryptionaround, it is only used to decide whether we want to accept verification gossip from the contact.Chat.is_protected()APIs.dc_contact_is_verifieddocumentation.