jdev - 2022-02-18

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?

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

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

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

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

(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.

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

and caps hash can be derived from feature-set

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

What about the rare case of caps injection?

What is caps injection?

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

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

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

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

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)

"the legacy format"?

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

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

0115 is broken but doesn't mention it anywhere?

that seems accurate

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

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

mailing list post from 2008 or so

as usual 😱️

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.

oh wow

I *guessed* 2008

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

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

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

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

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

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

More and more server-side forklift upgrade modules! ✏

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.

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

:<

Sam, 0411 has been superseded by 0402 though.

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

(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)

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

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

"deprecated but not superseded" I should say.

Oh, no, it is, nevermind

The big red thing at the top mentions both.

The one everyone conveniently skips. ^^'

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.

> 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)

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.

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

(for instance)

(nor for pubsub)

For anything not sending you its presence.

yeah

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).

This is also how we do it in slixmpp fyi.

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.

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

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

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

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

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

The big bright red place was not enough?

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

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

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

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

(or at least, I do)

Sam, I like it, thanks!

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

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

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.

probably not

By not worrying too much about it, I imagine.

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

You could also separate caches

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.

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

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

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

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

Yeah.

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

As in, use it internally

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

(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)

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

mod_ogp’s kind?

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

Link Mauve, yeah, somewhat

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

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

… or can we?

DON’T

:3

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

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

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?

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

Oh wow, that old!

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

And as that one game once said…

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

mplayer has a libaa backend

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

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