lovetoxi just added a feature, and this triggered hundreds of disco info requests
lovetoxthis behavior is not scaleable
lovetoxwe should do something about that
jonas’server-side caps optimization
ralphmlovetox: what's the use case?
Dele (Mobile)has left
admin1234cineva roman pe aici ?
admin1234Daniel esti roman ?
admin1234david esti roman ?
admin1234Kev help my please
lovetoxralphm, im not sure what you mean
lovetoxnot getting ddos'ed when you join some mucs?
Ge0rGThere is an experimental prosody module that will cache and auto deliver the disco#info for local clients.
Ge0rGUnfortunately it's full of race conditions and/or doesn't work on prosody stable.
ralphmlovetox: I didn't understand what you meant by you having added a feature.
ralphmBut now I do
lovetoxralphm, its even worse
Ge0rGlovetox: it's also the cause of a significant number of mobile wakeups, because there are also clients that join after you.
lovetoxbecause of a unfortunate example in the disco spec
lovetoxclient add version numbers under the identity name attr
lovetoxmeans every new version of that client, you get spammed with disco info
lovetoxeven though nothing changed about the caps
ZashThis is why I'm sceptical of version numbers in disco/caps
lovetoxin my opinion they should not be there, and nothing mandates that a version number has to be there
lovetoxits just devs put it there because its in one example i think
lovetoxwe have 0092 for version
lovetoxthere is no need to put this in disco info
ZashYeah. How often do you really need their version number?
lovetoxif i need it i request it
lovetoxof course it would be nice to have it in there, but the costs outweigh the benefits
lovetoxand yeah i really almost never need the version number
lovetoxonly if i display some details screen of the contact
lovetoxand if i open that its totally fine to send a 0092 request
Ge0rGlovetox: you could submit a PR fixing the example
ralphmBut then it would have to come with a note to discourage the version?
eevvoorlovetox 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
eevvoorlovetox 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.
ralphmAlso, 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.
ralphmAs a developer, yeah, that might be less nice.
DanielI think lovetox gets the worst of it because he is the one to first have a new hash
DanielBut I've made a note to remove the version from Conversations' cache
ralphmFrom disco info, you mean?
wurstsalateevvoor, there was a plugin once, but it didn't get ported to 1.0 I think
eevvoorwurstsalat, ah that is not long ago. cool, so there is something to build on.
Ge0rGThe implication is that you must not use the cache across JIDs
jonas’Ge0rG, huh? with XEP-0390 it should be safe, no?
ralphmThe whole idea of CAPS is that the hash is not related to the JID
Ge0rGjonas’: I think so. Did you ask waqas yet?
ZashWhat would you gain by such an attack anyways?
Ge0rGralphm: the JID is the security boundary in this case
jonas’Ge0rG, I did
Ge0rGjonas’: did he answer?
jonas’I don’t recall
Ge0rGThe XSF needs a new seal of approval, "Verified by waqas"
lovetoxthere is not a single security relevant feature in disco info that comes to mind, that usual clients currently use
lovetoxand 0390 is save against all the attacks mentioned?
jonas’it should betm
jonas’at least as long as we stay on XML 1.0 :)
lovetoxfrom a quick read, it seems not much work client side
flowjonas’, what happens if we don't stay xml 1.0?
Ge0rGflow: is there ecaps2 support in smack yet?
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)
ZashThen what? DER?
ZashOr other TLV-ish thing?
jonas’prefix them with NUL should be safe
Dele (Mobile)has joined
Ge0rGIs NUL illegal in XML 1.1? I anticipate that class of bugs.
lovetoxjonas’, why do we need a separator?
lovetoxits not like we are parsing the string we create again later
Ge0rGNo, but if you can create ambiguity, you can poison the cache with junk data
lovetoxah i get it
lovetoxbut then it seems better to take < as separator but make sure every value
lovetoxas it will always be illigal as a value
jonas’lovetox, < can easily be contained in form field values
lovetoxonly as lt or?
lovetoxnot 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.
lovetoxyou mean the lib converts < to < before you have access to it?
lovetoxyes this would be a problem
jonas’I sure hope the library does that, just like I sure hope that it does the reverse path
lovetoxnever thought about it, it just works :D
lovetoxbut yes i think it does also in my case
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
Douglas Terabytehas joined
ralphmI think it is unlikely we'd ever switch to 1.1.
Ge0rGjonas’: could you make ecaps2 future proof by prepending NUL to each separator?