Remove protected chats and expire auth tokens #7116
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
from
c7e6f1c to
e180d7f
Compare
link2xt
commented
Aug 16, 2025
| -----BEGIN PGP MESSAGE----- | ||
|
|
||
| wU4D5tq63hTeebASAQdATHbs7R5uRADpjsyAvrozHqQ/9nSrspwbLN6XJKuR3xcg |
Collaborator
Author
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
Collaborator
|
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 |
Collaborator
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? |
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
5 times, most recently
from
e60632e to
9abbe7a
Compare
iequidoo
approved these changes
Oct 17, 2025
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.
link2xt
force-pushed
the
link2xt/ykltkokxntvk
branch
from
9abbe7a to
afc74b0
Compare
Hocuri
added a commit
that referenced
this pull request
Oct 22, 2025
Context: PR #7116 is backwards-incompatible with versions older than v2.20, and since the release hasn't reached all users yet, we currently can't release from main; for details see #7326. Issue #7326 explains how we can make this less breaking, but this only works if many contacts are verified. So, this PR here proposes to postpone the stricter rules for who is verified a bit: - Set verification timeout for invite codes to 1 week (this is still stricter than no timeout at all, which we had in the past) - Don't reset indirect verifications yet (we should reset them in a few months then, but this is just so that we can release from main again, and release e.g. channels).
Hocuri
added a commit
that referenced
this pull request
Oct 22, 2025
Context: PR #7116 is backwards-incompatible with versions older than v2.20, and since the release hasn't reached all users yet, we currently can't release from main; for details see #7326. Issue #7326 explains how we can make this less breaking, but this only works if many contacts are verified. So, this PR here proposes to postpone the stricter rules for who is verified a bit: - Set verification timeout for invite codes to 1 week (this is still stricter than no timeout at all, which we had in the past) - Don't reset indirect verifications yet (we should reset them in a few months then, but this is just so that we can release from main again, and release e.g. channels).
Hocuri
added a commit
that referenced
this pull request
Oct 24, 2025
Context: PR #7116 is backwards-incompatible with versions older than v2.21, and since the release hasn't reached all users yet, we currently can't release from main; for details see #7326. Issue #7326 explains how we can make this less breaking, but this only works if many contacts are verified. So, this PR here proposes to postpone the stricter rules for who is verified a bit: - Set verification timeout for invite codes to 1 week (this is still stricter than no timeout at all, which we had in the past) - Don't reset indirect verifications yet In a few months (when everyone has v2.22.0), we can revert the PR here, then. --------- Co-authored-by: l <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.