What steps will reproduce the problem?
1. Send a <presence><priority>666</priority></presence>
What is the expected output? What do you see instead?
Prosody should filter that out, for example set it back to 0 (remove the priority element) or clamp it to the maximum value (127).
Instead it leaks that invalid stanza to the world.
What version of the product are you using? On what operating system?
No idea, this is coming from a contact.
Please provide any additional information below.
N/A
Zash
on
I believe we're following a philosophy of "garbage in, garbage out" here.
Changes
tags comp
Zash
on
Not sure if the RFC is that clear on what the server should do in this case. You could say that we override it (we clamp it into the correct range for the internal priority), so this should be reflected. But then, the client is violating a MUST, so the rules are already out the window.
Since this is a must, a stream:error could be worth it imo, telling the user to fix their client(’s configuration).
This would also be useful for invalid <show/> elements or <body/> containing children, for example.
What steps will reproduce the problem? 1. Send a <presence><priority>666</priority></presence> What is the expected output? What do you see instead? Prosody should filter that out, for example set it back to 0 (remove the priority element) or clamp it to the maximum value (127). Instead it leaks that invalid stanza to the world. What version of the product are you using? On what operating system? No idea, this is coming from a contact. Please provide any additional information below. N/A
I believe we're following a philosophy of "garbage in, garbage out" here.
ChangesNot sure if the RFC is that clear on what the server should do in this case. You could say that we override it (we clamp it into the correct range for the internal priority), so this should be reflected. But then, the client is violating a MUST, so the rules are already out the window.
ChangescompComplianceI already reported an issue to the client in question, but I guess a bunch of other clients will behave the same way: https://dev.gajim.org/gajim/gajim/issues/8630
Since this is a must, a stream:error could be worth it imo, telling the user to fix their client(’s configuration). This would also be useful for invalid <show/> elements or <body/> containing children, for example.