#1053 Prosody lacks the empty <subject/> message on MUC join in 0.9 and 0.10
Reporter
Jonas Wielicki
Owner
Zash
Created
Updated
Stars
★ (1)
Tags
Priority-Medium
Milestone-0.9
Type-Defect
Status-Fixed
Jonas Wielicki
on
What steps will reproduce the problem?
1. Join an empty/new prosody MUC with a client.
What is the expected output?
The MUC join should, after sending presence and possibly history, send a message with empty <subject/>.
What do you see instead?
No message with empty <subject/>.
What version of the product are you using? On what operating system?
0.10-ish: 7472:c72db8047440
0.9-ish: 5768:4e7269c53659
Debian testing
Please provide any additional information below.
This is in violation of XEP-0045#enter-subject (<https://xmpp.org/extensions/xep-0045.html#enter-subject>):
> If there is no subject set, the room MUST return an empty <subject/> element.
This is kinda bad, because clients cannot know this way when the replay of history is over. This has security implications: the lack of <presence/> in history makes it impossible to reason about identities in the history playback. However, in the actual conversation, due to the knowledge about joins/parts, it is in fact possible to do that. These two situations need to be clearly separated. A client relying on the <subject/> marker will treat the whole conversation as "untrusted", breaking UX in possibly bad ways.
What steps will reproduce the problem? 1. Join an empty/new prosody MUC with a client. What is the expected output? The MUC join should, after sending presence and possibly history, send a message with empty <subject/>. What do you see instead? No message with empty <subject/>. What version of the product are you using? On what operating system? 0.10-ish: 7472:c72db8047440 0.9-ish: 5768:4e7269c53659 Debian testing Please provide any additional information below. This is in violation of XEP-0045#enter-subject (<https://xmpp.org/extensions/xep-0045.html#enter-subject>): > If there is no subject set, the room MUST return an empty <subject/> element. This is kinda bad, because clients cannot know this way when the replay of history is over. This has security implications: the lack of <presence/> in history makes it impossible to reason about identities in the history playback. However, in the actual conversation, due to the knowledge about joins/parts, it is in fact possible to do that. These two situations need to be clearly separated. A client relying on the <subject/> marker will treat the whole conversation as "untrusted", breaking UX in possibly bad ways.
Fixed in https://hg.prosody.im/0.9/rev/0ec72e67f797
Changes