refactorings/preparations for introduce asymetrically encrypted keyupdates - #8620
refactorings/preparations for introduce asymetrically encrypted keyupdates #8620hpk42 wants to merge 3 commits into
Conversation
hpk42
changed the title
a871291 to
7c7c14e
Compare
| // and nothing else should come out of it: no contact, no chat, | ||
| // and no `last_seen` update lighting up an online dot. | ||
| info!(context, "Report without message reference (TRASH)."); | ||
| return trash().await; |
There was a problem hiding this comment.
not strictly neccessary but a short-cut to simplify reasoning about keyupdates in the future, to ensure the subsequent receive_imf code never sees this empty MDN.
There was a problem hiding this comment.
This code is only for users who upgraded, so we still need to check that nothing really bad happens on versions that don't have this code (contacts/chats appearing etc., not just the green dot). Having this code before key updates may hide problems if something other than green dot on the address-contact appears as a result.
EDIT: it is tested with test_keyupdate_against_core_2_48_march_2026 in #8621
No functional changes: Add a relay_addrs helper, share the protected headers and self-key rendering of non-chat messages, and move insert_into_smtp from securejoin to smtp.
…ages An unsigned message carries no intended recipient fingerprints, so recipients of an encrypted unsigned message learn nothing about other recipients from the PGP packets.
A report referencing no message can never be applied to one, so it must not create a contact, a chat or a `last_seen` update on its way to the trash.
7c7c14e to
715e1cc
Compare
| let encrypted = crate::pgp::symm_encrypt_message( | ||
| full_raw_message, | ||
| sign_key, | ||
| sign_key.cloned(), |
There was a problem hiding this comment.
Possibly no need for cloned() here (only in the call above) if it is not used afterwards and it is fine to move the key inside.
|
|
||
| /// Returns the protected headers shared by encrypted messages | ||
| /// that are not part of a chat. | ||
| async fn non_chat_protected_headers( |
There was a problem hiding this comment.
All headers are protected in some way except for Chat-Is-Post-Message, so not sure what protected means here.
| Ok(mime_parser) => mime_parser, | ||
| }; | ||
|
|
||
| if !mime_parser.mdn_reports.is_empty() |
There was a problem hiding this comment.
I tried commenting this out (if false &&), the test test_mdn_without_message_reference fails then but only because a contact is created that is not visible.
Without this "address-contact" probably still gets a green dot, not a problem because the user needs to create a visible address-contact chat first to even see this contact.
3 participants
This PR does not change any behaviour for code on main but contains the refactoring parts for introducing asynchronously encrypted key updates in #8621
IT should not be merged without also merging the actual keyupdate branch.