jdev - 2023-08-19

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

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.

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

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

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

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

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

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

Thanks!

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

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

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?

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.

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

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

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

Especially in moving between those models.

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

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

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

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

ok, thanks

sure you didnt' revert to dialback?

yep, because I was doing it with telnet :D

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

(through xmpp-proxy)

accidentally doing Dialback with Telnet would be impressive.

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

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

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

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

Yeah, I've read that article

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

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

file directory that is

Sure, if the room supports it

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

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

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

with SMS/SIMS

not sure which yet.

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

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

it seems its up in there for me still

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

fair

How about just sending a magnet URL?

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

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

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

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

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

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

So i could present a nice ui and such for it

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

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

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

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.