feat: add enforce_outer_from_key_alignment config for bots using addresses as identity#8433
Draft
hpk42 wants to merge 1 commit into
Draft
feat: add enforce_outer_from_key_alignment config for bots using addresses as identity#8433hpk42 wants to merge 1 commit into
hpk42 wants to merge 1 commit into
Conversation
Contributor
Author
…esses as identity If enabled (default is disabled) the processing of encrypted messages changes: - the outer From address must be listed as a relay address in the signing key, otherwise the message is trashed, - the sender contact keeps the outer From address instead of adopting the one from the encrypted part. Otherwise an attacker sending from their own relay-enforced address, with their own unmodified key, puts the victim's address into the encrypted From header and the contact address becomes the victim's. Arguably a fix: Autocrypt headers from the encrypted part are now accepted without comparing their address to the outer From, so that a newly added relay address is imported from the message before the check.
hpk42
force-pushed
the
hpk/outer-from-alignment
branch
from
July 20, 2026 11:41
198d98e to
285e8b0
Compare
hpk42
marked this pull request as draft
July 20, 2026 15:44
iequidoo
reviewed
Jul 20, 2026
iequidoo
left a comment
iequidoo
left a comment
Collaborator
There was a problem hiding this comment.
Commit message: feat: add enforce_outer_from_key_alignment config **needed** for bots using addresses as identity. Otherwise it's not clear whether this config only works in presense of Config::Bot (actually not)
| /// Only the outer From is enforced by the sender's relay, | ||
| /// so only it can be used as an identity. | ||
| #[strum(props(default = "0"))] | ||
| EnforceOuterFromKeyAlignment, |
Collaborator
There was a problem hiding this comment.
For me it looks like UseOuterFromAsContactAddr would be a better naming:
- It's what actually happens if the outer From differs from the inner one, but is still aligned with sender's key.
- Actually, alignment with the key is just an additional check which protects from the server changing the outer From to any address. The bot (or bot's server) still needs to check somehow (using DKIM i guess) that the outer From is actually owned by one who scanned the invite link.
- Alignment of the outer From with the key isn't checked if the outer From is the same as the inner one, and without reading the doc comment above it's not clear.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
this is meant for merging into #8382 to resolve the remaining loginbot vulnerability:
If the alignment option is enabled (default is disabled) the processing of encrypted messages changes:
the outer From address must be listed as a relay address in the signing key, otherwise the message is trashed,
the sender contact keeps the outer From address instead of adopting the one from the encrypted part.
Otherwise an attacker sending from their own relay-enforced address, with their own unmodified key, puts the victim's address into the encrypted From header and the contact address becomes the victim's.
Arguably a fix: Autocrypt headers from the encrypted part are now accepted without comparing their address to the outer From, so that a newly added relay address is imported from the message before the check.