i just added a feature, and this triggered hundreds of disco info requests
lovetox
this behavior is not scaleable
lovetox
we should do something about that
Alexhas left
jonas’
server-side caps optimization
Chobbeshas left
admin1234has joined
ralphm
lovetox: what's the use case?
rionhas left
rionhas joined
adityaborikarhas left
Dele (Mobile)has left
admin1234
cineva roman pe aici ?
admin1234
Daniel esti roman ?
admin1234
david esti roman ?
admin1234
admin1234 test
admin1234
Kev help my please
admin1234has left
Nekithas left
Nekithas joined
Yagizahas left
mimi89999has left
adityaborikarhas joined
lovetox
ralphm, im not sure what you mean
lovetox
not getting ddos'ed when you join some mucs?
Ge0rG
There is an experimental prosody module that will cache and auto deliver the disco#info for local clients.
Ge0rG
Unfortunately it's full of race conditions and/or doesn't work on prosody stable.
ralphm
lovetox: I didn't understand what you meant by you having added a feature.
ralphm
But now I do
lovetox
ralphm, its even worse
Ge0rG
lovetox: it's also the cause of a significant number of mobile wakeups, because there are also clients that join after you.
lovetox
because of a unfortunate example in the disco spec
lovetox
client add version numbers under the identity name attr
lovetox
means every new version of that client, you get spammed with disco info
lovetox
even though nothing changed about the caps
Zash
This is why I'm sceptical of version numbers in disco/caps
lovetox
in my opinion they should not be there, and nothing mandates that a version number has to be there
lovetox
its just devs put it there because its in one example i think
lovetox
we have 0092 for version
lovetox
there is no need to put this in disco info
Zash
Yeah. How often do you really need their version number?
lovetox
if i need it i request it
lovetox
of course it would be nice to have it in there, but the costs outweigh the benefits
mimi89999has joined
lovetox
and yeah i really almost never need the version number
lovetox
only if i display some details screen of the contact
lovetox
and if i open that its totally fine to send a 0092 request
adityaborikarhas left
Ge0rG
lovetox: you could submit a PR fixing the example
pdurbinhas joined
debaclehas joined
adityaborikarhas joined
pdurbinhas left
ralphm
But then it would have to come with a note to discourage the version?
Lancehas joined
eevvoor
lovetox does in gajim exist a bookmark export? jabber.de lost all bookmarks of some users during a downgrade in july I think. In Berlin_me✎
eevvoor
lovetox does in gajim exist a bookmark export? jabber.de lost all bookmarks of some users during a downgrade in july I think. In Berlin's Meetup MUC was discussed that so such export exists yet. ✏
ralphm
Also, I think in practice this isn't as much of an issue: the hash is cached for all users, so only the very first encounter of a new hash will cause a disco request.
ralphm
As a developer, yeah, that might be less nice.
Daniel
I think lovetox gets the worst of it because he is the one to first have a new hash
Daniel
But I've made a note to remove the version from Conversations' cache
ralphm
From disco info, you mean?
wurstsalat
eevvoor, there was a plugin once, but it didn't get ported to 1.0 I think
adityaborikarhas left
eevvoor
wurstsalat, ah that is not long ago. cool, so there is something to build on.
The implication is that you must not use the cache across JIDs
ralphm
Screw that
jonas’
Ge0rG, huh? with XEP-0390 it should be safe, no?
ralphm
The whole idea of CAPS is that the hash is not related to the JID
Ge0rG
jonas’: I think so. Did you ask waqas yet?
Zash
What would you gain by such an attack anyways?
Yagizahas joined
UsLhas joined
Ge0rG
ralphm: the JID is the security boundary in this case
jonas’
Ge0rG, I did
Ge0rG
jonas’: did he answer?
jonas’
I don’t recall
Ge0rG
The XSF needs a new seal of approval, "Verified by waqas"
lovetox
there is not a single security relevant feature in disco info that comes to mind, that usual clients currently use
lovetox
and 0390 is save against all the attacks mentioned?
jonas’
it should betm
jonas’
at least as long as we stay on XML 1.0 :)
debaclehas left
UsLhas left
lovetox
from a quick read, it seems not much work client side
kokonoehas left
kokonoehas joined
flow
jonas’, what happens if we don't stay xml 1.0?
Ge0rG
flow: is there ecaps2 support in smack yet?
j.rhas left
jonas’
flow, then the control characters used as separators become valid codepoints in XML (1.1) character data and are thus unsuitable as separators :)
jonas’
(for the hash function input)
Zash
Then what? DER?
Zash
Or other TLV-ish thing?
jonas’
prefix them with NUL should be safe
Dele (Mobile)has joined
Ge0rG
Is NUL illegal in XML 1.1? I anticipate that class of bugs.
lovetox
jonas’, why do we need a separator?
lovetox
its not like we are parsing the string we create again later
Ge0rG
No, but if you can create ambiguity, you can poison the cache with junk data
lovetox
ah i get it
lovetox
hm
adityaborikarhas left
lovetox
but then it seems better to take < as separator but make sure every value
lovetox
as it will always be illigal as a value
jonas’
lovetox, < can easily be contained in form field values
lovetox
only as lt or?
lovetox
not as <
jonas’
lovetox, not to your application.
jonas’
Ge0rG, yes, NUL is illegal in XML 1.1
jonas’
lovetox, we need to look at the codepoint representation, not at the wireformat. the wireformat *could* be littered with &#number;-based escape codes creating *lots* of ambiguity and breaking the hashes. not to mention that many XML libraries won’t even give you access to that.
lovetox
you mean the lib converts < to < before you have access to it?
lovetox
yes this would be a problem
jonas’
I sure hope the library does that, just like I sure hope that it does the reverse path
lovetox
never thought about it, it just works :D
lovetox
but yes i think it does also in my case
j.rhas joined
jonas’
so, yeah, you need to use a codepoint (or sequence of codepoints) which is invalid in XML character data as separator
jonas’
go-to approach which is safe for XML 1.1 would be NUL + something
ajhas left
Douglas Terabytehas joined
Mikaelahas left
Mikaelahas joined
Mikaelahas left
Mikaelahas joined
Nekithas joined
goffihas left
ralphm
I think it is unlikely we'd ever switch to 1.1.
matlaghas left
jonas’
me too
evehas left
evehas joined
neshtaxmpphas left
Alexhas joined
neshtaxmpphas joined
pdurbinhas joined
archas left
archas joined
curenhas left
pdurbinhas left
sezuanhas joined
sezuanhas left
j.rhas left
sezuanhas joined
Ge0rG
jonas’: could you make ecaps2 future proof by prepending NUL to each separator?