Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EncryptedFile examples containing mimetype #569

Open
deepbluev7 opened this issue Dec 2, 2019 · 4 comments
Open

EncryptedFile examples containing mimetype #569

deepbluev7 opened this issue Dec 2, 2019 · 4 comments
Labels
A-Client-Server Issues affecting the CS API A-E2EE Issues about end-to-end encryption spec-omission implemented but not currently specified

Comments

@deepbluev7
Copy link
Contributor

While looking at the spec of the EncryptedFile needed for attachment encryption, I noticed that all the examples contain a mimetype field, which is duplicated from the info subobject. The specification for EncryptedFile doesn't list that as an optional member though. Riot also seems to send this additional mimetype. So I'm wondering, should that be in the spec, are the examples wrong and why even is that field duplicated?

@turt2live turt2live added clarification An area where the expected behaviour is understood, but the spec could do with being more explicit A-Client-Server Issues affecting the CS API wart A point where the protocol is inconsistent or inelegant labels Dec 2, 2019
@turt2live turt2live added A-E2EE Issues about end-to-end encryption spec-omission implemented but not currently specified and removed clarification An area where the expected behaviour is understood, but the spec could do with being more explicit wart A point where the protocol is inconsistent or inelegant labels May 26, 2020
@uhoreg
Copy link
Member

uhoreg commented Jul 26, 2020

The original intention was that the mimetype is supposed to be duplicated, but was accidentally omitted when that was originally merged. However, MSC2582 is a proposal to drop the field.

@joepie91
Copy link

Following on from matrix-org/matrix-spec-proposals#2699:

(Since this is in the encrypted part of the event, this has nothing to do with Synapse.)

I'm not sure I'm following. The property in question is not, itself, encrypted - it just describes the data that is. Doesn't that make it something that the homeserver should be concerned about the validity of?

@deepbluev7
Copy link
Contributor Author

No, this applies only to encrypted events and since this is in content and not a relation, it is encrypted and the homeserver can't see it at all. file is only ever used in encrypted events, since it specifies how to decrypt it, so the homeserver can't ever validate it. The homeserver can only check, if it is sent unencrypted by accident.

@joepie91
Copy link

For posterity: after a brief chat with @deepbluev7 it turned out that the bit I overlooked was that the entire media event is getting encrypted, and so the homeserver never sees any of it, and that is why it can't be validated. It's clear now :)

@richvdh richvdh transferred this issue from matrix-org/matrix-spec-proposals Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Client-Server Issues affecting the CS API A-E2EE Issues about end-to-end encryption spec-omission implemented but not currently specified
Projects
None yet
Development

No branches or pull requests

4 participants