jdev - 2024-03-02


  1. andermillanlopez2

    Hello! How is everything? Has anyone by any chance used stanzaJS to create a plugin? I need to send some data via XMPP without users seeing that a message was sent, since it is to perform a validation. I am starting to use the XMPP protocol.

  2. lovetox

    No never used it, i think it should not be necessary to create a plugin, just to send some data

  3. lovetox

    plugins are usually developed in libraries to implement logic that many applicatons need, so it does not have to be added to every application

  4. jonas’

    how was this again, do I need to send initial presence in order to be allowed to send IQs to random entities (and get replies)?

  5. lovetox

    never heard of such a rule

  6. lovetox

    why would IQ be bound to presence?

  7. jonas’

    I seem to recall having had issues with IQs being blackholed when I hadn't sent initial presence.

  8. jonas’

    but that might also have been a buggy server

  9. MattJ

    jonas’, possibly in the old days of <session> that may have been a thing

  10. jonas’

    mhm, I remember servers requiring that even.

  11. jonas’

    so that might actually have been the same ancient server.

  12. MattJ

    iq (with full JIDs of course) should work without presence

  13. jonas’

    without full jids even?

  14. jonas’

    e.g. against domains or accounts?

  15. MattJ

    If you're sending out, you can send anywhere, yes

  16. jonas’

    right

  17. MattJ

    People can only send to your full JID if they know it, which is usually what presence achieves

  18. jonas’

    so if I were to reimplement the sjn crawler, I wouldn't bother with presence, because all I do is send IQs and process replies.

  19. jonas’

    hmm… I could even do a "timeout-less" design... I can just send IQs for disco#info, and process the replies as I get them, without having to track IDs. except maybe for disco#items with RSM, that could get funny otherwise.

  20. Zash

    Hm, do you even?

  21. Zash

    Doesn't RSM include enough state to do the next query?

  22. jonas’

    it should, yeah

  23. lovetox

    can a message have multiple <x xmlns='jabber:x:oob'> attached?

  24. singpolyma

    Surely

  25. MattJ

    Never ask singpolyma questions like that :P

  26. MattJ

    (but yes, I agree, I see no reason why it wouldn't be allowed)

  27. MattJ

    It makes more sense with a UI that presents them as "attachments", rather than inline media which is what we generally do these days

  28. singpolyma

    Inline previews for several attachments is a UI I have seen in other chat systems

  29. singpolyma

    What is do is "convert" them into the equivalent sims, dedupe against any actually present sims, and use sims as my internal storage format

  30. singpolyma

    What I do is "convert" them into the equivalent sims, dedupe against any actually present sims, and use sims as my internal storage format

  31. lovetox

    hm .. not sure i want to do that, it kind of says that oob will always be a file transfer

  32. lovetox

    which .. is not necessarily true in the future

  33. singpolyma

    You mean if you got some other kind of uri? Fair, I may have to rethink that normalization eventually

  34. lovetox

    but yeah there is no perfect way there, as we did brought this cluster fuck on our own

  35. lovetox

    but yeah there is no perfect way there, as we did bring this cluster fuck on our own

  36. singpolyma

    If you have multiple oob obviously the traditional "whole body is the one uri" fallback strategy fails but luckily we have the fallback xep now

  37. lovetox

    with omemo its at least a bit better, as it adds the aesgcm so you know its always a file that was uploaded

  38. singpolyma

    Yeah with an https and no head request you're just guessing the intent mostly

  39. singpolyma

    Which is part of why I'm moving towards sims, but need oob for most other clients for now

  40. singpolyma

    (and of course with omemo 1 we get no oob and no sims)

  41. Schimon

    Is Mr. Daniel Gultsch here?

  42. singpolyma

    Not at the moment, partly due to it being midnight where they are

  43. Schimon

    I have uploaded a "proof of concept" bot to showcase revelation of JID consequent to IQ in MUC https://gitgud.io/sjehuda/exploitiq

  44. Schimon

    Thank you singpolyma

  45. singpolyma

    Schimon: what is this bot?

  46. Schimon

    Ad-hoc command which shows a message with JID which sent a command to the bot

  47. Schimon

    Ad-hoc command which shows a message with JID of the person who sent a command to the bot

  48. singpolyma

    Oh this is the gajim/psi thing where they allow commands with semi anon participants but then transmit to any hit they are told without a warning

  49. singpolyma

    Oh this is the gajim/psi thing where they allow commands with semi anon participants but then transmit to any jid they are told without a warning

  50. Schimon

    Yes. Exactly! I will add instructions.

  51. singpolyma

    I think everyone understands the issue pretty clearly, but I guess having a simple demo can't hurt 🙂

  52. singpolyma

    I'm not affected mostly by accident because I never implemented commands to room participants

  53. moparisthebest

    > XMPP server administrators are encouraged to disable IQ in MUC and implement XEP-0000 which is more secure. What? I mean any clients that can be exposed like this need fixed

  54. singpolyma

    It's at most a UI issue

  55. singpolyma

    Not a protocol issue of any kind

  56. singpolyma

    It's also not related to "iq in MUC" not really

  57. lovetox

    moparisthebest, whats the exploit part here?

  58. lovetox

    As i see it, at most there should be a info message that says, "if you send adhoc commands to muc participants you can reveal your JID"

  59. Schimon

    lovetox, I agree https://dev.gajim.org/gajim/gajim/-/issues/11756

  60. moparisthebest

    > As i see it, at most there should be a info message that says, "if you send adhoc commands to muc participants you can reveal your JID" Yes, unless there are other ways it can be exposed too

  61. Schimon

    I have added instructions (promoting Gajim) https://gitgud.io/sjehuda/exploitiq#about

  62. moparisthebest

    > accelerate the transfer from MUC to MIX Lol what does this have to do with anything

  63. Schimon

    moparisthebest, I think it is a good idea. Present the issue, and by doing so, you motivate server operators to deprecate XEP-0045.

  64. lovetox

    Schimon, you are blowing this a bit up, its not an exploit, its just the way the protocol works, a simple information for the user mitigates the whole issue. Nobody needs to disable IQ or PMs or implement new standards ..

  65. moparisthebest

    Schimon: I don't think anyone is actually planning to do that, mix solves nothing

  66. Schimon

    > > XMPP server administrators are encouraged to disable IQ in MUC and implement XEP-0000 which is more secure. > What? I mean any clients that can be exposed like this need fixed moparisthebest: I am not an expert nor have clear understanding of XMPP. This is an opinion someone else has made, and I convey it.

  67. moparisthebest

    Who said it :)