XSF Discussion - 2022-02-10


  1. Neustradamus

    moparisthebest: Good job!

  2. moparisthebest

    https://github.com/BombusMod/BombusMod/issues/130#issuecomment-1034360835 wins for fastest fix (that I know of)

  3. emus

    regarding CVEs, can this be reviewed? https://github.com/xsf/xmpp.org/pull/1007 Ge0rG?

  4. emus

    regarding CVEs, can this be reviewed? https://github.com/xsf/xmpp.org/pull/1001 Ge0rG?

  5. edhelas

    Movim is not using _xmppconnect and not connecting using BOSH or WS, just for you to know

  6. edhelas

    So I shoudn't be affected

  7. jonas’

    moparisthebest, *raises hat* good find

  8. jonas’

    I did not realize this despite looking into _xmppconnect more closely for xmppnetv2

  9. jonas’

    I do not like that the result is more HTTP though.

  10. jonas’

    but that's, for once, not your fault :)

  11. Link Mauve

    emus, where is that 404 page used? I get the regular nginx page on unknown pages. :(

  12. emus

    https://github.com/xsf/xmpp.org/pull/1001

  13. emus

    dunno whats not working

  14. Link Mauve

    Yes, the 404 page from this PR.

  15. Link Mauve

    I didn’t even know we had one.

  16. emus

    can you review for pr 1001

  17. wurstsalat

    Link Mauve, it's a standard page from the default theme (not used atm)

  18. Link Mauve

    Oh, I see, thanks. :)

  19. Link Mauve

    larma, in XEP-0446, why did you go for @dimensions (width"x"height) instead of the more common @width and @height?

  20. Holger

    I'm late to the _xmppconnect party, and not into JavaScript. I was assuming the browser wouldn't even permit DNS queries (and that .well-known was invented for this reason). So that's not true?

  21. Zash

    DoH to the "rescue" ?

  22. Zash

    But you can use JavaScript outside of browsers, e.g. with FirefoxOS and such, which may have both raw TCP sockets and real DNS APIs

  23. Holger

    Well sure, plus you can obviously use WebSocket outside of JavaScript, but then why wouldn't I be able to verify the certificate just as with plain TCP (non-WebSocket) access?

  24. MattJ

    Which certificate would you verify?

  25. MattJ

    JS is even more limited in this regard

  26. MattJ

    If you make a request to https://evil.com/http-bind, the browser will naturally just verify the cert is for evil.com

  27. Holger

    Ah. So the issue is about the combinartion "WebSocket with JavaScript outside the browser (i.e. Node.js)"?

  28. MattJ

    Javascript isn't relevant to the issue at all, really

  29. MattJ

    Any client that uses the DNS lookup to obtain this info is using an insecure protocol to obtain connection info

  30. Holger

    As I said my (mis?)understanding was that querying TXT records from within the browser wasn't even possible in the first place.

  31. Zash

    You're receiving a connection endpoint over an insecure channel, you must not allow it to alter the identifier you compare the certificate to.

  32. MattJ

    That's usually *not* JS stuff, because they use the HTTPS discovery alternative instead

  33. Holger

    Sure.

  34. MattJ

    So most/all JS clients are probably unaffected

  35. Zash

    Unless they somehow do http:///.well-know ...

  36. MattJ

    That would be more work, and typically blocked by browsers these days afaik

  37. MattJ

    (if the script itself is loaded over https:// )

  38. Holger

    I'm definitely missing something :-)

  39. Zash

    Holger, this affects desktop clients doing _xmppconnect TXT lookups

  40. Zash

    e.g. Pidgin will automatically pick up on _xmppconnect and connect over BOSH

  41. MattJ

    Holger, '156 defines two methods of advertisement: DNS and HTTPS. Everything using DNS is insecure.

  42. Holger

    How's their situation different from desktop clients performing an SRV lookup?

  43. Zash

    (unless DNSSEC ... 😭️)

  44. Holger

    Well. Gajim uses DNS.

  45. MattJ

    Because when you do SRV lookup you verify the cert against the original domain

  46. Zash

    (also modulo DNSSEC)

  47. Holger

    Yes.

  48. MattJ

    You know you want to connect to "example.com", so when SRV tells you to connect to xmpp.evil.com, you verify you get a cert for 'example.com' still

  49. Holger

    My question remains, why can't the desktop client perform an _xmppconnect lookup, connect over BOSH, and verify the cert against the original domain.

  50. MattJ

    (for the purposes of this whole discussion, DNSSEC doesn't exist)

  51. MattJ

    It could

  52. MattJ

    So it could connect to https://evil.com/ and expect it to serve a cert for example.com instead?

  53. Holger

    That's what I would've assumed, sure.

  54. MattJ

    This is a very unusual configuration in the web world, and would require some hoops to jump through to set up

  55. Zash

    Probably tricky to convince every HTTPS library to do taht

  56. Zash

    Probably tricky to convince every HTTPS library to do that

  57. MattJ

    But yes, if you did it that way it would not be insecure

  58. Zash

    NSS supposedly made it impossible (which ruled out SRV records even)

  59. MattJ

    But everyone just grabs the URL and passes it to their HTTP stack

  60. Holger

    Oh so the issue is server-side. I hadn't thought of that.

  61. Holger

    Ok yes plus maybe client-side HTTP library APIs. I see.

  62. MattJ

    I'm pretty sure if you serve a BOSH URL of https://evil.com/ with a cert of https://example.com/ 100% of everything is going to break trying to load that URL

  63. MattJ

    as it should, really

  64. MattJ

    In the past when implementing '156 for something, I did verify that the domain of the endpoint was the same as the XMPP domain, otherwise ignore it

  65. Holger

    I see.

  66. Zash

    MattJ, I would imagine that you were the only one

  67. Zash

    Oh, you mean for xmpp:example.com assert https://example.com/* ?

  68. MattJ

    Yes

  69. MattJ

    https://mail.jabber.org/pipermail/standards/2011-May/024460.html

  70. Zash

    That, or perhaps a subdomain, ought to be safe, yeah

  71. MattJ

    "This problem will go away in the distant future when DNSSEC is more readily available" -- 2011

  72. Zash

    E.g. I'd expect https://xmpp.example.com/bosh for xmpp:example.com to be fairly common

  73. MattJ

    https://logs.xmpp.org/xsf/2017-10-04#2017-10-04-f931006edc04c07d

  74. MattJ

    Kudos to moparisthebest for... actually doing something :P

  75. Link Mauve

    larma, you mention “Hash the resulting string using the algorithm choosen for the sticker pack.” in XEP-0449, does it mean you want to allow only a single hash, instead of the usual hash agility thingy?

  76. Link Mauve

    Would XEP-0103 also be useful to distribute cid: URIs? I wouldn’t expect so.

  77. Link Mauve

    But if not, should we create another XEP for shipping stickers that way?

  78. moparisthebest

    it mainly annoys me that I must have read '156 multiple dozens of times, and fully implemented and end-to-end tested websocket support, and only noticed it during some light refactoring before the final push https://github.com/moparisthebest/xmpp-proxy/blob/master/src/srv.rs#L77

  79. moparisthebest

    and it's surprisingly bad because even though a client does all *other* starttls/tls validation correctly, this is all it takes, an attacker can just block those and force a connection over websocket to gain mitm

  80. Link Mauve

    The hashing algorithm in XEP-0449 isn’t clear, especially around hashes.

  81. Link Mauve

    Should I encode the bytes of the hash, or its base64 representation?

  82. Link Mauve

    I’d rather the former, as it is what gets out of my parser.

  83. Link Mauve

    Having a complete example like in XEP-0390 would be useful.

  84. larma

    Link Mauve, - re dimensions: The reason was, originally, that the field shouldn't require exactly 2 dimensions, although the description indeed now reads like that. Maybe width and height would indeed be easier in practice. - re hash: the ID needs to be one ID. I guess if you put two hashes on the pack, you can pick any of the two as your hash for ID generation - re cid: I don't think 0103 is a good fit for cid uris. I also don't really see the need and future for cid URIs anyway. Instead just use Jingle with IBB which is effectively the same functionality just that the payload doesn't need to fit in one stanza.

  85. Link Mauve

    larma, other dimensions, such as for a 3D sticker for instance?

  86. larma

    446 is for any kind of file, not just stickers. But yes, 3d stickers

  87. jonas’

    what about non-spatial dimensions?

  88. Link Mauve

    Ah right, I forgot the part where the ID is also truncated and reused for the id.

  89. Link Mauve

    Why is it truncated btw?

  90. Link Mauve

    In XEP-0084 it isn’t for instance.

  91. larma

    jonas’, I think 3d is not far off reality. You could already want to transfer 3d object files which also have dimensions.

  92. Link Mauve

    larma, the idea about cid: was to be compatible with existing clients, like Movim.

  93. Link Mauve

    larma, what about cube map textures?!

  94. Link Mauve

    How do you encode each of the six sides?

  95. larma

    That's up for future specification 😉

  96. Link Mauve

    larma, I made https://github.com/xsf/xeps/pull/1160 and https://github.com/xsf/xeps/pull/1161 fyi.

  97. larma

    Does Movim not support http file uris or jingle ibb?

  98. Link Mauve

    Not for stickers AIUI.

  99. Link Mauve

    edhelas, ↑

  100. larma

    So... A sticker is an image file transferred via BoB where an image file transferred via http/jingle is not?

  101. larma

    So... A sticker is an image file transferred via BoB when an image file transferred via http/jingle is not?

  102. edhelas

    Movim stickers are cid:

  103. edhelas

    you can always send a link and Movim will resolve it

  104. edhelas

    but it's not a sticker "for me", just an image

  105. edhelas

    I also support SIMS

  106. edhelas

    https://xmpp.org/extensions/xep-0385.html

  107. edhelas

    but also as an "'attached image"

  108. larma

    So the only way to send a sticker to Movim is to send cid via <img> in deprecated XHTML-IM?

  109. moparisthebest

    > "This problem will go away in the distant future when DNSSEC is more readily available" -- 2011 this is one of the saddest things I've ever read :'(

  110. Link Mauve

    Let’s undeprecate XHTML-IM.

  111. larma

    Or not use XHTML-IM for stickers?

  112. larma

    <sticker xmlns="custom" uri="cid:bla" /> would have worked as well, no?

  113. edhelas

    Movim doesn't support XHTML-IM, only the cid: :p

  114. Link Mauve

    Re 0446, it’s always been weird to me even back when it was called 0234 to have various metadata about specific file types.

  115. Link Mauve

    Why dimensions and length, and not number of words in the epub, or target hardware for a video game?

  116. edhelas

    https://github.com/movim/movim/blob/master/app/Message.php#L273

  117. Link Mauve

    Filesystems don’t usually provide this kind of information, so the sender would have to parse the file.

  118. Link Mauve

    That is optional, but it still seems like feature creep to me.

  119. edhelas

    Link Mauve yup, I don't trust the info :p

  120. Link Mauve

    It’s not about trust or not, it’s about whether or not it makes sense in file metadata.

  121. larma

    Link Mauve, the hashes and values in the example 1 of xep 0449 are actual real values, and apparently I took the file hash as base64 string. You can't use bytes directly because bytes could include 0x1F.

  122. larma

    Also regarding dimensions: It's so that you can display a sensible placeholder in correct size before fetching the file

  123. Zash

    But why as one complex attribute instead of two simple integer ones?

  124. larma

    And length is so that you can display also that for audio and video before fetching the file, it's what most other chat systems do as well

  125. Link Mauve

    Oh, with the <!-- ... --> I thought it wasn’t complete.

  126. moparisthebest

    parse the images they said, it'll be fun easy and safe they said... https://www.kuow.org/stories/we-didn-t-mean-to-ruin-your-mazda-s-stereo

  127. Link Mauve

    But then I can only test whether I get the correct result or not, not see where I did something wrong like with XEP-0390.

  128. larma

    Zash, I agree that this would be a sensible option if we only have 2d images/videos in mind (and honestly, that's what we have right now, so probably better to not overengineer here)

  129. Link Mauve

    moparisthebest, an image of the system, aka an update, right?

  130. Link Mauve

    Not an image with pixels.

  131. moparisthebest

    Link Mauve, no, literally an image with pixels

  132. Link Mauve

    larma, ok, so I have to reencode to base64.

  133. Zash

    Wait what?

  134. mjk

    The image placeholders in GUIs are usually 2D because our screens usually too... But then again, the sender shouldn't dictate how their cube of 3D MIP-mapped images shall be projected on the receiver's sceen

  135. moparisthebest

    Link Mauve, more technical article https://www.theregister.com/2022/02/10/mazda_radios_images/

  136. Link Mauve

    mjk, skyboxes in video games have been cube maps for about as long as 3D hardware has existed.

  137. mjk

    With the above I mean: don't limit metadata to WxH, leave space for extensibility :)

  138. mjk

    Link Mauve: Er. Yes. And? :))

  139. larma

    Link Mauve, `summary\x1fen\x1fBe cute or be cynical, this little kitten works both ways.\x1ename\x1fen\x1fMarsey the Cat\x1e\x1c👍\x1esha-256\x1f0AdP8lJOWJrugSKOIAqfEKqFatIpG5JBCjjxY253ojQ=\x1f\x1e\x1d😘\x1esha-256\x1fgw+6xdCgOcvCYSKuQNrXH33lV9NMzuDf/s0huByCDsY=\x1f\x1e\x1d\x1c` is the bytes for the sticker pack in example 1 which hash to the hash given in the Example. For reference, the two image files are https://larma.de/xeps/xep-0449-1.png and https://larma.de/xeps/xep-0449-2.png

  140. mjk

    I'm well-versed in my skyboxes :p

  141. Link Mauve

    Thanks!

  142. Link Mauve

    larma, I couldn’t have guessed @xml:lang was "en". :)

  143. Link Mauve

    I default to "" if it isn’t set, in xmpp-parsers.

  144. Zash

    My 5D chess videos!

  145. Link Mauve

    “Join the resulting octet strings together, ordered from lesser to greater.”, isn’t summary > name here?

  146. Link Mauve

    In your example it’s in the other way.

  147. larma

    Meh, yeah, you're right. The field was named desc once and when I renamed it I forgot to reorder that part

  148. Link Mauve

    larma, fyi you’re also missing a \x1f after the content of the name and summary fields.

  149. Link Mauve

    With this one fix, I’m now compatible with your hash!

  150. Kev

    This one simple fix to your hash doctors don't want you to know.

  151. larma

    I remember there was some issue with the hash as well, have to double check my notes from back then

  152. Link Mauve

    Also, the desc should probably take one \x1f after, as this is done for every single other field.

  153. Link Mauve

    Re section 4.2, I think it would make sense for backwards compatibility to include the image as oob.

  154. ralphm bangs gavel

  155. jcbrand

    hi

  156. ralphm

    0. Welcome

  157. ralphm

    Hi! Who do we have?

  158. jcbrand

    MattJ?

  159. jcbrand

    Looks like arc is not here

  160. ralphm unbangs gavel

  161. arc

    We really need to get ourselves better organized

  162. Link Mauve

    The recommendation to use XEP-0363 for hosting the stickers, in section 4.4, is going to crash pretty quickly with real world server configurations, where the ttl of such a file might be just one week.

  163. Zash

    Also remember Daniel mentioning that in the context of avatars

  164. Link Mauve

    Thankfully avatars are still mostly served in-band.

  165. Zash

    Since you can't put them in http upload because they expire

  166. Link Mauve

    Let’s keep it like that then. :D

  167. moparisthebest

    s/thankfully/unfortunately/

  168. moparisthebest

    Avatars are pretty much the only reason stanza size limits are exceeded

  169. Link Mauve

    If someone wants to hammer me with a 1 MiB avatar, I’d rather their connection get closed.

  170. moparisthebest

    It's more of an s2s problem

  171. moparisthebest

    Like the person in this room who had the massive avatar

  172. Zash

    On that topic, can we replace XEP-0153 with micro-images instead? (think blurhash)

  173. Zash

    moparisthebest, Link Mauve, with their INFINITE avatar?

  174. Zash

    Note for the archives: Link Mauve has an SVG avatar

  175. moparisthebest

    That would be fun, unfortunately (for the "fun") most servers have implemented sane stanza size limits by now?

  176. Zash

    Peek at server logs and look for s2s collapses

  177. Link Mauve

    My avatar isn’t infinite, it is just the size you want. :)

  178. Link Mauve

    Any size you want.

  179. moparisthebest

    Link Mauve doesn't have an avatar at all for me, or it's infinitely small, I'll never know

  180. Zash

    Multi-format/multi-resolution avatars when?

  181. Zash

    moparisthebest, you can still have fun if you find someone with even lower stanza size limits than everyone else

  182. Zash

    When will I finish that path MTU XEP?

  183. Zash

    Srsly tho, squeeze avatars into the size of a hash and use that instead of a hash of the actual profile image!

  184. moparisthebest

    Is that spec/code free?

  185. Zash

    Can you send one 8x8 block of JPEG?

  186. Zash

    And like, remove the redundant parts

  187. Zash

    ie the "this is an 8x8 px JPEG" part

  188. Zash

    Someone suggested doing that instead of blurhash previously

  189. Zash

    It was larma, https://logs.xmpp.org/xsf/2020-11-22?p=h#2020-11-22-ea01a0735a4bc25e

  190. Zash

    or?

  191. Zash

    upscaled PNG something something

  192. larma

    I'd suggest to go for even smaller, like 3x2 PX. And then you're better of to use a very simple image format (think bmp or the likes)

  193. larma

    And yeah, then just upscale them in a blurry way

  194. larma

    Would be even better to use image formats that are good in supporting low color depth, because you also don't really need that

  195. Link Mauve

    Use a single chunk of BC7, this is 16 bytes, and it is supported by every GPU.

  196. Link Mauve

    Using exactly one quarter of the size it would be in RGBA8888.

  197. Zash

    Maybe take a bit or two to mean "circle, rounded corners, square, ????"

  198. Link Mauve

    The downside is that it only supports multiples of 4×4, so 3×2 wouldn’t be any smaller.

  199. Link Mauve

    I recently wrote an implementation of BC7 and it was pretty fun.

  200. Link Mauve

    (A software implementation.)

  201. Zash

    in poezio when?

  202. Link Mauve

    :D

  203. Link Mauve

    Zash, the Genshin Impact stickers actually come from this decoder. :)

  204. Link Mauve

    Since in the game data they are stored in BC7.

  205. Link Mauve

    PNG often compresses more, these stickers.

  206. Link Mauve

    Not for all of them.

  207. Zash

    Acquire some Unicode madness and render avatars in group chat views in like 2x3 pixels!

  208. larma

    Actually, I like the idea to use BC7. We just need a mime type for "single bc7 chunk"

  209. Link Mauve

    At 8×8, in base64, we have an image of higher quality than blurhash, for the exact same size.

  210. larma

    and yeah, it only doing 4x4 is a bit problematic, when you think of images that are rather wide, like 21:9 resolutions

  211. Zash

    Profile images are all square so that's not a problem 🙂

  212. Zash

    but you're also thinking of previews for file transfers?

  213. larma

    yes, mostly thinking about those

  214. Link Mauve

    larma, you can always put in the metadata that it actually is 4×3, and the recipient client will crop out the last line of pixels.

  215. Link Mauve

    We already have XEP-0264 for that though.

  216. larma

    yes, but those use URIs which either is a BoB cid (requiring sender to be online at time of recipient wanting to fetch the thumbnail) or an external http uri (in which case I can just fetch the real thing and hope that it is encoded in a way that would allow to render early)

  217. larma

    It could be a data uri if we agree on a file format for those

  218. Link Mauve

    Reminds me to check for AVIF support of embedded thumbnails.

  219. Link Mauve

    It was annoyingly not part of the first specification.

  220. mjk

    > Maybe take a bit or two to mean "circle, rounded corners, square, ????" 3D! We also need to think about three-dimensional avatars and how to round them

  221. Zash

    "circle, rounded corners, square, you need more bits"

  222. mjk

    right

  223. Zash

    let's just do 1D avatars

  224. MattJ

    I've seen discussion of star-shaped avatars for Conversations 3.0

  225. Zash

    or nD? how many dimension should you curl up the string of pixels into?

  226. mjk

    > let's just do 1D avatars that's... like... `alt`?

  227. Link Mauve

    I’ve tried to associate emoji to the various stickers I’ve used today, but it’s pretty hard.

  228. Link Mauve

    Is it just me, or is it not fully doable?

  229. Zash

    Isn't that the point?

  230. Link Mauve

    Sure, but then the <desc/> might not really be usable.

  231. Link Mauve

    A proper description (what I’d put in an @alt text) would be better imo.

  232. Link Mauve

    larma, for the next version of XEP-0449, it would be very nice to have format agility too.

  233. Link Mauve

    Since (as moparisthebest exhibited) not every client supports SVG yet, it would be sensible to provide an AVIF fallback.

  234. Link Mauve

    And perhaps even resolution agility, since not everyone needs a 512×512 Marsay the Cat.

  235. Link Mauve

    Perhaps using multiple <file/> elements? But then the sources don’t match any longer…

  236. larma

    Link Mauve, format agility and not using <desc/> is also on the to do already (was discussed on standards@ IIRC)

  237. Link Mauve

    Oh.

  238. larma

    I just didn't have a lot of time recently (did I mention we have video conferences in Dino :D)

  239. Link Mauve

    (Yes! <3)

  240. Link Mauve

    There should be a TODO section in experimental XEPs!

  241. Link Mauve

    So that we wouldn’t give feedback you already have thought about. :)

  242. Zash

    Aren't ProtoXEPs with TODO sections rejected?

  243. Link Mauve

    Are they?

  244. Link Mauve

    Make it “future work” then.

  245. moparisthebest

    TODO is short for "this will never be done ever" right ?

  246. emus

    Kev, would you mind to join the GSoC muc to discuss or give your input on the task discussion? So asking for your GSoC experiences if you want to contribute to the discussion

  247. emus

    gsoc@muc.xmpp.org