jdev - 2023-08-19

  1. Guus

    moparisthebest: Openfire still requires the inbound server to provide an authzid, which I believe stems from the distant past

  2. Guus

    XEP-0178 mentions the practice in an interop note: > Interoperability Note: Previous versions of this specification stated that the receiving server always relied on the connecting server's inclusion of the authorization identity. Even though this is no longer required, the connecting server SHOULD include the authorization identity for backward compability.

  3. Guus

    (shouldn't that be 'compatibility' instead of 'compability' by the way?)

  4. Guus

    I'll see if we can get this improved in Openfire

    ๐ŸŽ‰๏ธ 1
  5. Zash

    Doesn't feel critical but one day it'd be nice to reduce the number of roundtrips involved there.

  6. moparisthebest

    > I'll see if we can get this improved in Openfire Awesome, thanks Guus ! The challenge that doesn't seem possible to respond to is mainly what threw me but I suppose fixing it the other way is better :)

  7. jonasโ€™

    edhelas, *if* you reset the read status, there must be a strong indication when the user switches to that conversation which message has been edited how

  8. Guus

    moparisthebest: https://igniterealtime.atlassian.net/browse/OF-2639

  9. moparisthebest


  10. Zash

    Don't most servers send their own name in the <auth> message while allowing others to send = ?

  11. moparisthebest

    I assume they all do for interop reasons, but they all accept = except openfire so if that's fixed servers should start being able to send = after awhile

  12. moparisthebest

    Having the name in there seems like a potential source of security bugs, I wonder if the xep should be updated to suggest just ignoring it?

  13. Zash

    It's in there because `from` on the stream used to be optional so you had no idea until that point who you were talking to.

  14. moparisthebest

    ooohhhhh that wasn't clear to me at all, but now makes sense, thanks for that

  15. Zash

    In the Dialback era, streams had no fixed to/from, you could add arbitrary to-from pairs at any time.

  16. Zash

    If there are security bugs, I'd bet on that.

  17. Zash

    Especially in moving between those models.

  18. Zash

    Like what happens if you put the server behind a reverse proxy, without access to certs and keys for SASL EXTERNAL use...

  19. moparisthebest

    then it becomes the reverse proxy's responsibility to verify those, like xmpp-proxy makes sure the provided cert is valid for the domain in the stream 'from' before even forwarding to the XMPP server

  20. Guus

    Looking at this more, I'm not liking how Openfire's SASL EXTERNAL mechanism doesn't explicitly verify the identities from the certificate against the stream's `from` value. It is likely checked during TLS, but still.. moparisthebest, if you're up for more bug hunting...

  21. moparisthebest

    Guus, well I did try to establish a s2s stream to igniterealtime.org with a valid cert and an incorrect domain yesterday and it wouldn't let me, so it's doing that right as far as I can tell

  22. Guus

    ok, thanks

  23. Guus

    sure you didnt' revert to dialback?

  24. moparisthebest

    yep, because I was doing it with telnet :D

  25. Guus

    (also: we're rewriting most of the networking stack, so all of this might be different in the next release)

  26. moparisthebest

    (through xmpp-proxy)

  27. Guus

    accidentally doing Dialback with Telnet would be impressive.

  28. moparisthebest

    Guus, https://github.blog/2023-08-17-mtls-when-certificate-authentication-is-done-wrong/ is what made me test all this, just don't make those mistakes and you should be good :D

  29. moparisthebest

    java has a *terrible* API there, handing you an array of certs, having only verified the first

  30. Guus

    Openfire has a mix of using that API, BouncyCastle's, and homegrown stuff - which isn't necessarily an improvement.

  31. moparisthebest

    Bouncy castle basically does the same, they found a few flaws in it too

  32. Guus

    Yeah, I've read that article

  33. MSavoritias (fae,ve)

    Is it possible for XEP-0234: Jingle File Transfer to send the file to the room? Like http upload i am guessing does

  34. MSavoritias (fae,ve)

    so that clients can request the file from the room "directory"

  35. MSavoritias (fae,ve)

    file directory that is

  36. singpolyma

    Sure, if the room supports it

  37. MSavoritias (fae,ve)

    i guess i am asking to "attach" stuff to the room with that xep

  38. singpolyma

    Also possible to use sims to publish a file hash and then use jingle ft in "pull" mode to request the hash from the sender

  39. MSavoritias (fae,ve)

    yeah that was my thinking. basically use it in public rooms to publish a torrent file

  40. MSavoritias (fae,ve)

    with SMS/SIMS

  41. MSavoritias (fae,ve)

    not sure which yet.

  42. singpolyma

    I'm planning to add jingle pull based on sims soon, just didn't get to it yet

  43. MSavoritias (fae,ve)

    nice. is there any push for SMS or are we going full in on SIMS?

  44. MSavoritias (fae,ve)

    it seems its up in there for me still

  45. singpolyma

    Depends who you ask. I'm all in on sims

  46. MSavoritias (fae,ve)


  47. moparisthebest

    How about just sending a magnet URL?

  48. singpolyma

    If you're going to actually use BitTorrent for the transfer then sure

  49. MSavoritias (fae,ve)

    > How about just sending a magnet URL? like in the chat?

  50. MSavoritias (fae,ve)

    or with jingle. with jingle yeah probably just a magnet makes sense

  51. singpolyma

    Sims you can optionally have multiple alternative URIs as well as the metadata

  52. moparisthebest

    I just meant in the chat, then people can click on it

  53. MSavoritias (fae,ve)

    One thing is that i want all group chat file sharing to happen through that. Like pictures

  54. MSavoritias (fae,ve)

    So i could present a nice ui and such for it

  55. moparisthebest

    does that mean like bundling a torrent client into the XMPP client?

  56. MSavoritias (fae,ve)

    Good question no idea. Also it seems torrents are incompatible with other choices i have made for my client so.. more reading required ๐Ÿ˜

  57. Guus

    I'm taking a go on implementing https://xmpp.org/extensions/inbox/xep-reporting-account-affiliations.html in Openfire. When doing the embedding of the 'info' element, is it sufficient to process/modify inbound, client-originating stanzas? My first thought was to add these to _outbound_ stanzas (stanzas being delivered by the server to other clients or federated servers), but it proves difficult to be able to reliably find the original local user for an outbound stanza (an outbound MUC stanza could have originated from a user on a remote domain, but even if it's not, the 'from' address now is a room address).

  58. Guus

    I'm worried that by operating on client-originating, inbound stanzas only, I will miss adding info elements to stanzas generated by the server on the user's behalf.