jdev - 2022-02-18


  1. Sam

    This is probably me being stupid, because I'm sure that I've done this before, but how do you get entity caps for the account JID? You're not likely to have a presence subscription to yourself and the stream feature is for the server, so if you need to check if your own account supports something you have to just do a disco#info request and can't cache the caps hash, I guess?

  2. Zash

    Something about giving clients a pile of (jid, caps-hash) pairs is on my XEP wishlist.

  3. Zash

    I may even have a prototype somewhere, tho focused on e.g. components

  4. jonas’

    Sam, I don't think that the account even gives you a disco#info caps hash

  5. Sam

    So I have to store features mapped to JIDs and features mapped to hashes mapped to JIDs? That doesn't seem ideal.

  6. Sam

    (but it tracks with how everything in XMPP is special cased; I also just discovered that there's *another* bookmarks compatibility thing I forgot about in 0411 and the whole time I was looking at conversations code it was actually using that and not the PEP native stuff, so I'm about ready to table flip and give up on developing an XMPP client at this point). Thanks for the confirmation anyways.

  7. Zash

    Hmm, JID→feature-set mapping seems sensible to have, no?

  8. Zash

    and caps hash can be derived from feature-set

  9. Sam

    Sure, it's sensible by itself, but not if I *also* have to do a JID->caps->feature-set and keep both and check both just in case a jid has or does not have caps

  10. Zash

    What about the rare case of caps injection?

  11. Sam

    What is caps injection?

  12. Zash

    or whatsitcalled, if someone manages to have two disco#info sets with the same caps

  13. Zash

    or whatsitcalled, if someone manages to have two disco#info sets with the same caps-hash

  14. Sam

    That would be bad, but it seems reasonable to assume the hash method is safe and that's not going to happen.

  15. Zash

    Wasn't the current disco#info and caps broken that way already due to something with separator characters?

  16. Sam

    *facepalm* of course it would be, I'll have to look

  17. Sam

    There's a security considerations mention of caps poisoning, but it only mentions it for the legacy format (which I'm not bothering to support)

  18. jonas’

    "the legacy format"?

  19. Sam

    It's part of the spec. Caps was updated at some point so the spec contains a bunch of "how to be compatible with old caps" stuff

  20. jonas’

    to be clear: 0115 is still broken. 0390 is not broken, or at least I wouldn't know it was

  21. Sam

    0115 is broken but doesn't mention it anywhere?

  22. jonas’

    that seems accurate

  23. jonas’

    nothing stops you from stuffing a `>` in some var or so to generate a collision

  24. Sam

    Where can I find info about this? It seems *really* important that it be in the security considerations section or something

  25. jonas’

    mailing list post from 2008 or so

  26. Zash

    as usual 😱️

  27. Sam

    I really should just give up on XMPP, this is infuriating. Rage quitting for the day and will get back to this later. Thanks for letting me know.

  28. jonas’

    oh wow

  29. jonas’

    I *guessed* 2008

  30. jonas’

    it is in fact 2009, so I wasn't that far off

  31. jonas’

    https://mail.jabber.org/pipermail/security/2009-July/000812.html

  32. Zash

    https://xmpp.org/extensions/xep-0390.html#intro mentions it

  33. jonas’

    and the acknowledgements have a link to the mentioned mailing list post

  34. Zash

    You're right it should be added as a warning to '115

  35. jonas’

    hm, I should push for advancement of '390 and make us deprecate '115

  36. Zash

    More and more server forklift upgrade modules!

  37. Zash

    More and more server-side forklift upgrade modules!

  38. jonas’

    Sam, oh, so there's a bandaid in '115: > Note: If the four characters '&', 'l', 't', ';' appear consecutively in any of the factors of the verification string S (e.g., a service discovery identity of 'SomeClient&lt;http://jabber.org/protocol/muc') then that string of characters MUST be treated as literally '&lt;' and MUST NOT be converted to the character '<', because completing such a conversion would open the protocol to trivial attacks.

  39. jonas’

    but this is unclear, weird and I would be surprised if it was watertight (what about `&amp;lt;`?) or if everyone implements this correctly

  40. Zash

    :<

  41. Link Mauve

    Sam, 0411 has been superseded by 0402 though.

  42. Sam

    Link Mauve: yup, I'm using 0402. Turns out Other things are still using 0411 though.

  43. Sam

    (it also appears deprecated, not superseded, but that's a minor nit; it would just be easier to discover the new thing if we updated, that, might be worth doing at some point; adding it to my list of cleanup stuff to do / mail the list about)

  44. Link Mauve

    Superseded means another specification provides the same usecase, while deprecated and obsolete are statuses for the specification itself.

  45. Link Mauve

    A specification can be deprecated/obsoleted without any superseding one.

  46. Sam

    "deprecated but not superseded" I should say.

  47. Sam

    Oh, no, it is, nevermind

  48. Link Mauve

    The big red thing at the top mentions both.

  49. Link Mauve

    The one everyone conveniently skips. ^^'

  50. Sam

    I do the same thing every time (look at column headers for a "suprseded by" and don't read the boilerplate text that is different sometimes. Just a formatting thing.

  51. pulkomandy

    > The big red thing at the top mentions both. > The one everyone conveniently skips. ^^' The web trained us to ignore big flashing bright things because usually, they are ads and not relevant content (there is an ux study about this somewhere)

  52. Sam

    Anyways, regardless, back to the original issue: apparently I have to treat the account disco different from every other disco because I can't use caps for the first but can for everything else.

  53. jonas’

    Sam, no, you cannot use caps for MUC either, for instance

  54. jonas’

    (for instance)

  55. jonas’

    (nor for pubsub)

  56. Link Mauve

    For anything not sending you its presence.

  57. jonas’

    yeah

  58. jonas’

    Sam, FWIW, how I do it in aioxmpp is that the disco#info client code has a cache and the caps code listens for presences and injects stuff in the disco#info cache based on (validated) caps hash -> disco#info mappings (which it may also look up).

  59. Link Mauve

    This is also how we do it in slixmpp fyi.

  60. Sam

    Cool, thank for confirming. I've got a lot of rewriting to do, but it's likely not happening this morning or I'm going to lose it. Time to step away from the computer and stop dealing with this for now. Thanks again.

  61. jonas’

    pulkomandy, FTR, I skipped any kind of headers even before I started using the web ;)

  62. Zash

    What's that, we need a deprecated+see-other-XEP metacombo?

  63. jonas’

    check in the xslt if there's any superseded by?

  64. Sam

    It's in the appendix as well; I'm going to submit a PR to add it to the top in a (hopefully?) more visible way too before I head out

  65. Sam

    Okay, I fixed at least the most minor of the things that have been bothering me this morning. I feel slightly better: https://github.com/xsf/xeps/pull/1167

  66. Link Mauve

    The big bright red place was not enough?

  67. Link Mauve

    “Developers desiring similar functionality are advised to implement the protocol that supersedes this one (XEP-0402).” ← here.

  68. Sam

    It's easier to pull data out of a table quickly than it is to find it in paragraph

  69. Link Mauve

    “Developers desiring similar functionality are advised to implement the protocol that supersedes this one (XEP-0402).” ← here.

  70. Link Mauve

    “Developers desiring similar functionality are advised to implement the protocol that supersedes this one (XEP-0402).” ← here.

  71. Sam

    Plus this is a standard warning so you don't expect it to change so you glance right over it and don't read it because you've read it a thousand times before and it doesn't include a link at the end

  72. Sam

    (or at least, I do)

  73. jonas’

    Sam, I like it, thanks!

  74. jonas’

    will be in the next round of XEP rebuilds (tuesday)

  75. Sam

    jonas’: Thanks, that should fix me always missing that anyways

  76. Sam

    How are others defending against the pre-image attacks listed in this email from earlier? I'm back at my desk now and I can do the note the XEP mentions for attack 1, but as the email mentioned I see no way it's possible to defend against some of the others. Attack 4 can be worked around, but are people doing that? the XEP doesn't even mention that one.

  77. jonas’

    probably not

  78. Zash

    By not worrying too much about it, I imagine.

  79. jonas’

    Sam, there's a reason I made XEP-0390 after all

  80. Zash

    You could also separate caches

  81. Sam

    yah, that's what I suspected. That's unfortunate. Maybe it's not worth actually implementing the fix since there will be other trivial ones that can't be fixed.

  82. Link Mauve

    I usually try to make sure to have one cache per JID, which somewhat defeats the point.

  83. Link Mauve

    I also try to advocate for XEP-0390, but with few results so far.

  84. Link Mauve

    I made a Prosody module which gives 0390 hashes to every local user which has published caps.

  85. Zash

    Doesn't defeat the point, I think, you reduce traffic to 1 query per client/change at least.

  86. Link Mauve

    Yeah.

  87. Zash

    And it's probably possible to store the data efficiently, if you e.g. use the '390 algorithm or some XML normalization to deduplicate the disco#info payloads

  88. Zash

    As in, use it internally

  89. mathieui

    do we have some kind of consensus-ish view on how media cards should be standardized in XMPP?

  90. mathieui

    (the main issue here in my opinion is privacy considerations, should a server proxy/cache media if it can, what should be the default, etc)

  91. Zash

    do we have some kind of definition of what "media cards" are?

  92. Link Mauve

    mod_ogp’s kind?

  93. mathieui

    I think twitter has the gist of it, declined differently on all the different platforms though of course, https://developer.twitter.com/en/docs/twitter-for-websites/cards/overview/abouts-cards

  94. mathieui

    Link Mauve, yeah, somewhat

  95. mathieui

    ofc there is also the question of embedding media & players, which is done through iframes in the various web things

  96. Link Mauve

    Right, we can’t really have iframes in poezio.

  97. Link Mauve

    … or can we?

  98. mathieui

    DON’T

  99. Link Mauve

    :3

  100. Link Mauve

    I think what we’re really lacking in poezio so far is WebGL.

  101. Link Mauve

    Thankfully, I have a half-block backend in GLFW, using a render node directly!

  102. mathieui

    can’t we run a virtual display with llvmpipe enabled, then run a webgl-capable browser in fullscreen and take 30 screenshots a second, converted to half-blocks?

  103. Link Mauve

    https://linkmauve.fr/files/wayland-screenshot-2019-12-24_20-54-26.png

  104. Link Mauve

    Oh wow, that old!

  105. Link Mauve

    mathieui, nah, llvmpipe is too slow, I’d rather poezio use my server’s GPU!

  106. Link Mauve

    And as that one game once said…

  107. Link Mauve

    https://linkmauve.fr/files/wayland-screenshot-2020-08-23_01-05-06.png

  108. jonas’

    mplayer has a libaa backend

  109. Link Mauve

    And mpv has --vo=tct, which was my source of inspiration. :)

  110. Link Mauve

    If I still had a Khronos sponsorship, I could have added an EGL platform for the terminal!