XSF Discussion - 2022-02-10

moparisthebest: Good job!

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

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

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

So I shoudn't be affected

moparisthebest, *raises hat* good find

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

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

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

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

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

dunno whats not working

Yes, the 404 page from this PR.

I didn’t even know we had one.

can you review for pr 1001

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

Oh, I see, thanks. :)

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

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?

DoH to the "rescue" ?

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

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?

Which certificate would you verify?

JS is even more limited in this regard

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

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

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

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

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

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

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

Sure.

So most/all JS clients are probably unaffected

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

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

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

I'm definitely missing something :-)

Holger, this affects desktop clients doing _xmppconnect TXT lookups

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

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

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

(unless DNSSEC ... 😭️)

Well. Gajim uses DNS.

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

(also modulo DNSSEC)

Yes.

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

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

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

It could

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

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

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

Probably tricky to convince every HTTPS library to do that ✏

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

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

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

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

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

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

as it should, really

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

I see.

MattJ, I would imagine that you were the only one

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

Yes

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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.

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

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

what about non-spatial dimensions?

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

Why is it truncated btw?

In XEP-0084 it isn’t for instance.

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

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

larma, what about cube map textures?!

How do you encode each of the six sides?

That's up for future specification 😉

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

Does Movim not support http file uris or jingle ibb?

Not for stickers AIUI.

edhelas, ↑

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

Movim stickers are cid:

you can always send a link and Movim will resolve it

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

I also support SIMS

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

but also as an "'attached image"

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

> "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 :'(

Let’s undeprecate XHTML-IM.

Or not use XHTML-IM for stickers?

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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.

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)

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

Not an image with pixels.

Link Mauve, no, literally an image with pixels

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

Wait what?

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

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

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

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

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

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

I'm well-versed in my skyboxes :p

Thanks!

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

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

My 5D chess videos!

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

In your example it’s in the other way.

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

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

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

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

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

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

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

hi

0. Welcome

Hi! Who do we have?

MattJ?

Looks like arc is not here

We really need to get ourselves better organized

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.

Also remember Daniel mentioning that in the context of avatars

Thankfully avatars are still mostly served in-band.

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

Let’s keep it like that then. :D

s/thankfully/unfortunately/

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

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

It's more of an s2s problem

Like the person in this room who had the massive avatar

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

moparisthebest, Link Mauve, with their INFINITE avatar?

Note for the archives: Link Mauve has an SVG avatar

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

Peek at server logs and look for s2s collapses

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

Any size you want.

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

Multi-format/multi-resolution avatars when?

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

When will I finish that path MTU XEP?

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

Is that spec/code free?

Can you send one 8x8 block of JPEG?

And like, remove the redundant parts

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

Someone suggested doing that instead of blurhash previously

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

or?

upscaled PNG something something

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)

And yeah, then just upscale them in a blurry way

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

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

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

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

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

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

(A software implementation.)

in poezio when?

:D

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

Since in the game data they are stored in BC7.

PNG often compresses more, these stickers.

Not for all of them.

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

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

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

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

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

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

yes, mostly thinking about those

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.

We already have XEP-0264 for that though.

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)

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

Reminds me to check for AVIF support of embedded thumbnails.

It was annoyingly not part of the first specification.

> 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

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

right

let's just do 1D avatars

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

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

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

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

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

Isn't that the point?

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

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

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

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

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

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

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

Oh.

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

(Yes! <3)

There should be a TODO section in experimental XEPs!

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

Aren't ProtoXEPs with TODO sections rejected?

Are they?

Make it “future work” then.

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

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

gsoc@muc.xmpp.org