XSF Discussion - 2019-08-17

  1. lovetox

    it is getting ridicoulous with disco info

  2. lovetox

    i just added a feature, and this triggered hundreds of disco info requests

  3. lovetox

    this behavior is not scaleable

  4. lovetox

    we should do something about that

  5. jonas’

    server-side caps optimization

  6. ralphm

    lovetox: what's the use case?

  7. admin1234

    cineva roman pe aici ?

  8. admin1234

    Daniel esti roman ?

  9. admin1234

    david esti roman ?

  10. admin1234

    admin1234 test

  11. admin1234

    Kev help my please

  12. lovetox

    ralphm, im not sure what you mean

  13. lovetox

    not getting ddos'ed when you join some mucs?

  14. Ge0rG

    There is an experimental prosody module that will cache and auto deliver the disco#info for local clients.

  15. Ge0rG

    Unfortunately it's full of race conditions and/or doesn't work on prosody stable.

  16. ralphm

    lovetox: I didn't understand what you meant by you having added a feature.

  17. ralphm

    But now I do

  18. lovetox

    ralphm, its even worse

  19. Ge0rG

    lovetox: it's also the cause of a significant number of mobile wakeups, because there are also clients that join after you.

  20. lovetox

    because of a unfortunate example in the disco spec

  21. lovetox

    client add version numbers under the identity name attr

  22. lovetox

    means every new version of that client, you get spammed with disco info

  23. lovetox

    even though nothing changed about the caps

  24. Zash

    This is why I'm sceptical of version numbers in disco/caps

  25. lovetox

    in my opinion they should not be there, and nothing mandates that a version number has to be there

  26. lovetox

    its just devs put it there because its in one example i think

  27. lovetox

    we have 0092 for version

  28. lovetox

    there is no need to put this in disco info

  29. Zash

    Yeah. How often do you really need their version number?

  30. lovetox

    if i need it i request it

  31. lovetox

    of course it would be nice to have it in there, but the costs outweigh the benefits

  32. lovetox

    and yeah i really almost never need the version number

  33. lovetox

    only if i display some details screen of the contact

  34. lovetox

    and if i open that its totally fine to send a 0092 request

  35. Ge0rG

    lovetox: you could submit a PR fixing the example

  36. ralphm

    But then it would have to come with a note to discourage the version?

  37. 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

  38. 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.

  39. 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.

  40. ralphm

    As a developer, yeah, that might be less nice.

  41. Daniel

    I think lovetox gets the worst of it because he is the one to first have a new hash

  42. Daniel

    But I've made a note to remove the version from Conversations' cache

  43. ralphm

    From disco info, you mean?

  44. wurstsalat

    eevvoor, there was a plugin once, but it didn't get ported to 1.0 I think

  45. eevvoor

    wurstsalat, ah that is not long ago. cool, so there is something to build on.

  46. Daniel

    ralphm: yes

  47. ralphm

    lovetox: which example is it?

  48. wurstsalat

    eevvoor, https://dev.gajim.org/gajim/gajim-plugins/tree/gajim_0.16/offline_bookmarks

  49. eevvoor

    thx wurstsalat

  50. lovetox

    ralphm, https://xmpp.org/extensions/xep-0115.html#howitworks

  51. lovetox

    scroll a bit down

  52. lovetox

    yeah and i guess as developer im getting the worst of it

  53. lovetox

    but in Gajim exist plugins that alter the disco info to announce support for some feature

  54. lovetox

    But either way a server caching disco infos would be great

  55. lovetox

    i dont see any drawbacks

  56. Ge0rG

    lovetox: race conditions when you change the caps at runtime

  57. lovetox

    do you have an example?

  58. lovetox

    i dont see a problem there, server gets a request for a hash, either he has it then he answers, or not then he routes the IQ

  59. Zash

    You're supposed to include the caps hash in the @node when querying, so that should be detectable

  60. Ge0rG

    Zash: some clients ignore that @node

  61. lovetox

    Ge0rG, how is this relevant?

  62. Zash

    "Some clients are broken"

  63. Ge0rG

    And IIRC we have the issue that the node value can be gamed

  64. lovetox

    ok you lost me

  65. Ge0rG

    Where's caps 2.0 when you need it

  66. Ge0rG

    lovetox: https://xmpp.org/extensions/xep-0390.html

  67. Ge0rG


  68. Zash


  69. Ge0rG

    The implication is that you must not use the cache across JIDs

  70. ralphm

    Screw that

  71. jonas’

    Ge0rG, huh? with XEP-0390 it should be safe, no?

  72. ralphm

    The whole idea of CAPS is that the hash is not related to the JID

  73. Ge0rG

    jonas’: I think so. Did you ask waqas yet?

  74. Zash

    What would you gain by such an attack anyways?

  75. Ge0rG

    ralphm: the JID is the security boundary in this case

  76. jonas’

    Ge0rG, I did

  77. Ge0rG

    jonas’: did he answer?

  78. jonas’

    I don’t recall

  79. Ge0rG

    The XSF needs a new seal of approval, "Verified by waqas"

  80. lovetox

    there is not a single security relevant feature in disco info that comes to mind, that usual clients currently use

  81. lovetox

    and 0390 is save against all the attacks mentioned?

  82. jonas’

    it should betm

  83. jonas’

    at least as long as we stay on XML 1.0 :)

  84. lovetox

    from a quick read, it seems not much work client side

  85. flow

    jonas’, what happens if we don't stay xml 1.0?

  86. Ge0rG

    flow: is there ecaps2 support in smack yet?

  87. jonas’

    flow, then the control characters used as separators become valid codepoints in XML (1.1) character data and are thus unsuitable as separators :)

  88. jonas’

    (for the hash function input)

  89. Zash

    Then what? DER?

  90. Zash

    Or other TLV-ish thing?

  91. jonas’

    prefix them with NUL should be safe

  92. Ge0rG

    Is NUL illegal in XML 1.1? I anticipate that class of bugs.

  93. lovetox

    jonas’, why do we need a separator?

  94. lovetox

    its not like we are parsing the string we create again later

  95. Ge0rG

    No, but if you can create ambiguity, you can poison the cache with junk data

  96. lovetox

    ah i get it

  97. lovetox


  98. lovetox

    but then it seems better to take < as separator but make sure every value

  99. lovetox

    as it will always be illigal as a value

  100. jonas’

    lovetox, < can easily be contained in form field values

  101. lovetox

    only as lt or?

  102. lovetox

    not as <

  103. jonas’

    lovetox, not to your application.

  104. jonas’

    Ge0rG, yes, NUL is illegal in XML 1.1

  105. 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.

  106. lovetox

    you mean the lib converts &lt; to < before you have access to it?

  107. lovetox

    yes this would be a problem

  108. jonas’

    I sure hope the library does that, just like I sure hope that it does the reverse path

  109. lovetox

    never thought about it, it just works :D

  110. lovetox

    but yes i think it does also in my case

  111. jonas’

    so, yeah, you need to use a codepoint (or sequence of codepoints) which is invalid in XML character data as separator

  112. jonas’

    go-to approach which is safe for XML 1.1 would be NUL + something

  113. ralphm

    I think it is unlikely we'd ever switch to 1.1.

  114. jonas’

    me too

  115. Ge0rG

    jonas’: could you make ecaps2 future proof by prepending NUL to each separator?

  116. jonas’

    Ge0rG, it’s in the queue

  117. jonas’

    I might actually have the diff somewhere