jdev - 2024-04-21

  1. lovetox


  2. lovetox

    as i read the schema, either start and end are missing, or both are set

  3. lovetox

    its not possible to only set start or end

  4. lovetox

    is my interpretation correct?

  5. singpolyma

    I think so

  6. lovetox

    thanks, one other thing i want clarified, is there a difference between empty <body /> tag and no <body /> tag

  7. lovetox

    i think i read, there is a difference, empty body tag means only the body is a fallback, but not the subject

  8. lovetox

    no childs, would mean both subject and body is fallback

  9. singpolyma

    I think no childs should be invalid

  10. lovetox

    its not, its specifically defined

  11. lovetox

    > If start and end attribute are not supplied, the whole respective message element should be assumed to be there for fallback purposes. If the <fallback/> element does not have any childs, it is assumed to apply to every message <body/> and <subject/> present in the message.

  12. singpolyma

    That's unfortunate. I'd suggest to change that

  13. lovetox

    but would that not make trouble if you include multiple bodys

  14. lovetox

    say you add 10 bodys in 10 languages all fallback

  15. lovetox

    does that mean in need to add 10 empty body elements to the fallbackj

  16. lovetox

    does that mean in need to add 10 empty body elements to the fallback

  17. lovetox

    seems easier to have a "everything is a fallback" way out

  18. lovetox

    ah mom, bit weird to define no childs, makes it hard to extend

  19. lovetox

    with new stuff, it probably say, no body or subject

  20. singpolyma

    Would you not add just one body?

  21. MSavoritias (fae,ve)

    how do xmpp software know when the packet is finished if there is no framing?

  22. singpolyma

    There is framing

  23. singpolyma

    Just no extra framing beyond xml

  24. moparisthebest

    MSavoritias (fae,ve): ugh my pet peeve, by parsing the XML of course! And yes bugs where different XML parsers have found different "endings" have caused major security issues

  25. singpolyma

    Basically stuff all the bytes as they come into your streaming (event based or otherwise) xml parser. Done

  26. singpolyma

    In the common example of an even based parser you'll get start tag and end tag events

  27. MSavoritias (fae,ve)

    so i have to parse all the stanza i get even if its 2gb until it stops or i see an ending sign?

  28. MSavoritias (fae,ve)

    so what happens if there is no "end tag"?

  29. moparisthebest

    Yea don't do that, good way to run out of memory

  30. singpolyma

    MSavoritias (fae,ve): or abort the connection due to stanza too large yes

  31. MSavoritias (fae,ve)

    ah so every xml parser/xmpp software has a max size and after that it aborts

  32. MSavoritias (fae,ve)

    then again i guess the sender could lie in framing too

  33. singpolyma

    Every xmpp server does, so as a client you probably don't have to care

  34. singpolyma

    > then again i guess the sender could lie in framing too Of course

  35. moparisthebest

    With framing it's an extra safety layer though, you know up front if it's too large to bother, you read that amount (efficiently), and you easily decide if it's a whole stanza or not

  36. singpolyma

    Sure, if you're a c programmer and have no XML parser it might help

  37. singpolyma

    Framing over already framed stuff (like JSON or XML) is my nemesis

  38. moparisthebest

    MSavoritias (fae,ve): alternativly you can support only XMPP over websocket which has framing 🥲

  39. singpolyma

    And needs weird hacks to compensate for that

  40. MSavoritias (fae,ve)

    > Every xmpp server does, so as a client you probably don't have to care well i am the server and the client ;) thats why i asked

  41. singpolyma

    Certainly no one should invent their *own* framing. Websocket and beep exist

  42. moparisthebest

    What strange hacks?

  43. MSavoritias (fae,ve)

    can framing be added at the tcp layer?

  44. singpolyma

    MSavoritias (fae,ve): right. So server you almost definitely want to enforce a stanza size limit. So once you've read N bytes without an end, abort

  45. MSavoritias (fae,ve)

    theoretically i mean. or is it only xmpp level

  46. MSavoritias (fae,ve)

    singpolyma, makes sense

  47. singpolyma

    Even smtp and http servers do this

  48. moparisthebest

    MSavoritias (fae,ve): https://code.moparisthebest.com/moparisthebest/xmpp-proxy/src/branch/master/src/stanzafilter.rs is how I seperate individual stanzas without a XML parser and without allocating memory

  49. singpolyma

    > What strange hacks? Like <begin/>

  50. MSavoritias (fae,ve)

    will look thank you moparisthebest

  51. moparisthebest

    Yes we can add framing at the stream level, last time I floated the idea many were generally in favor

  52. moparisthebest

    >> What strange hacks? > Like <begin/> I too think that was a mistake, completely unneeded though, stream open would have fit in there fine

  53. singpolyma

    > Yes we can add framing at the stream level, last time I floated the idea many were generally in favor Ew. If we do let's at least use websocket. But also let's not

  54. singpolyma

    I'd be much more interested in multi-stream or multi-modal as those solve real problems

  55. singpolyma

    WT can give us both if we want

  56. moparisthebest

    WebTransport isn't framed at all

  57. singpolyma


  58. singpolyma

    But it can do multi stream and multi modal

  59. singpolyma

    Which solve actual problems

  60. moparisthebest

    MSavoritias (fae,ve): here's the security issue framing would have prevented https://bugs.chromium.org/p/project-zero/issues/detail?id=2254 that's 2 bugs in 2 different FOSS XML parsers, one in gloox and the other in ejabberd (iirc the one in gloox still hasn't been fixed to this day)

  61. MSavoritias (fae,ve)

    how can we actually prevent the issue that is in the background section at protocol level tho? > A surprising fact (to me at least) about XMPP, is that the client has full control over the XML code inside the message <body> tag. For example, if one client alters the message body to include a valid XML snippet like for example (note the <foo> and <bar> tags):

  62. MSavoritias (fae,ve)

    shouldnt the sending client be able to include whatever they want

  63. moparisthebest

    the ejabberd bug is arguably an expat bug which many things use, I can't recall where/how it was fixed regardless this brings up my other pet peeve which is imho no XMPP project should use off-the-shelf XML libraries, XMPP uses a *tiny & safe* subset of XML, and enabling XML features outside that has been a constant source of security flaws in XMPP

  64. singpolyma

    MSavoritias (fae,ve): indeed. That's not surprising it's the whole point

  65. wgreenhouse

    moparisthebest: yeah it was fixed in expat, and indirectly in ejabberd

  66. singpolyma

    Stream arbitrary xml, call it a protocol, that's us

  67. moparisthebest

    Yea I don't understand why that's surprising or a problem at all...

  68. MSavoritias (fae,ve)

    is there a page about differences between xmp and xmpp-xml?

  69. moparisthebest

    Likely only the XMPP RFC ?

  70. MSavoritias (fae,ve)


  71. singpolyma

    Ideally we'd eliminate those anyway

  72. singpolyma

    I think the only real one is apparently xmpp bans comments just to be difficult

  73. wgreenhouse

    singpolyma: it means that when I see comments in jabber.el xmlconsole, I know it's because the client put them there :P

  74. moparisthebest

    > I think the only real one is apparently xmpp bans comments just to be difficult singpolyma: processing instructions?

  75. singpolyma

    moparisthebest: that's just a different kind of comment :P

  76. moparisthebest

    iirc a few other absolutely horrific things from a security perspective

  77. singpolyma

    DTDs if you consider those part of base XML)'- i certainly do not

  78. MSavoritias (fae,ve)

    wouldnt a DTD be a good idea as a seperate document? or maybe it would be too large

  79. MSavoritias (fae,ve)

    then again maybe there is no benefit /thinking

  80. lovetox

    we can only pray that nobody will ever start using fallback indication wth multiple lang bodys

  81. lovetox

    this will be the source of countless bus :D

  82. lovetox

    this will be the source of countless bugs :D

  83. lovetox

    is there a usecase to provide a fallback text without "for" attribute?

  84. singpolyma

    I dont think so