Repository navigation
fix(matrix): use standard Base64 for E2EE attachment IV - #1788
Merged
caronc merged 6 commits intoOct 16, 2026
Merged
Conversation
Codecov Reportâ
All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1788 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 246 246
Lines 40290 40307 +17
Branches 6950 6957 +7
=========================================
+ Hits 40290 40307 +17
ð New features to boost your workflow:
|
Owner
|
Thank you again for your PR! ð |
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
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.
Description
Related issue (if applicable): None â fixes a Matrix E2EE attachment encoding bug.
Encrypted Matrix image/file attachments sometimes fail to render in Matrix clients even when the attachment event is successfully delivered. A strict client reports an error such as:
The Matrix encrypted attachment format uses Base64URL for the JWK encryption key (
file.key.k), but requires standard, unpadded Base64 for the initialization vector (file.iv).The existing
encrypt_attachment()implementation usesbase64.urlsafe_b64encode()for the IV too. Depending on the random IV, this generates-or_characters, which are rejected by strict Base64 decoders. This explains why the problem occurs intermittently.This PR changes the IV encoding to:
The change does not modify AES-256-CTR encryption, generated IV bytes, JWK key encoding, or the ciphertext hash.
A regression test forces an IV whose standard Base64 representation contains
/rather than_, verifies that the serialized IV uses standard Base64, and checks successful AES-256-CTR decryption.Matrix specification: https://spec.matrix.org/latest/client-server-api/#sending-encrypted-attachments
Checklist
tox -e lintand optionallytox -e format). (Not yet run locally.)tox -e qa). (Regression test added; execution pending.)Testing
Anyone can help test as follows:
For integration testing, configure an E2EE-enabled Matrix room and send image attachments repeatedly.
Verify that attachments remain readable in Element and other strict Matrix clients, including when the generated IV contains
+or/.No live Matrix credentials are required for the regression test.