lovetoxi just added a feature, and this triggered hundreds of disco info requests
lovetoxthis behavior is not scaleable
lovetoxwe should do something about that
Alexhas left
jonas’server-side caps optimization
Chobbeshas left
admin1234has joined
ralphmlovetox: what's the use case?
rionhas left
rionhas joined
adityaborikarhas left
Dele (Mobile)has left
admin1234cineva roman pe aici ?
admin1234Daniel esti roman ?
admin1234david esti roman ?
admin1234admin1234 test
admin1234Kev help my please
admin1234has left
Nekithas left
Nekithas joined
Yagizahas left
mimi89999has left
adityaborikarhas joined
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
mimi89999has joined
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
adityaborikarhas left
Ge0rGlovetox: you could submit a PR fixing the example
pdurbinhas joined
debaclehas joined
adityaborikarhas joined
pdurbinhas left
ralphmBut then it would have to come with a note to discourage the version?
Lancehas joined
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
adityaborikarhas left
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
ralphmScrew that
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?
Yagizahas joined
UsLhas joined
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 :)
debaclehas left
UsLhas left
lovetoxfrom a quick read, it seems not much work client side
kokonoehas left
kokonoehas joined
flowjonas’, what happens if we don't stay xml 1.0?
Ge0rGflow: 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)
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
lovetoxhm
adityaborikarhas left
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
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
ralphmI 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
Ge0rGjonas’: could you make ecaps2 future proof by prepending NUL to each separator?