jdev - 2023-11-04

Another p2p contender enters the ring https://unsigned.io/website/sideband/ > It does not need a connection to a server

But wait, what's this: > LXM Propagation Nodes offer a way to store and forward messages to users or endpoints that are not directly reachable at the time of message emission. Propagation Nodes can also provide infrastructure for distributed bulletin, news or discussion boards. Oh no! 🤣

XMPP might be the only P2P network honest enough to call servers servers?

> But wait, what's this: > > LXM Propagation Nodes offer a way to store and forward messages to users or endpoints that are not directly reachable at the time of message emission. Propagation Nodes can also provide infrastructure for distributed bulletin, news or discussion boards. > Oh no! 🤣 Laught in Pubsub ↺

That sounds like a worse version of briar's mailbox. Which is itself a worse version of gnunet's way of store and forward. Oh well

moparisthebest, the answer to the "what's this" is "marketing!"

> They are tricky and have been the source of countless security bugs that could have been entirely avoided with framing Objection. Hyperbole. ↺

Do you want a list of vulns or :)

https://bugs.chromium.org/p/project-zero/issues/detail?id=2254 is the most recent that comes to mind

Prosody running out of memory on unlimited length stanzas is another

Countless == 2? Now how many off-by-one and buffer over/underflow bugs have there been?

You'd have both though, the belt and suspenders approach

There will be bugs either way.

You'd have a buffer that's supposed to have exactly 1 stanza in it, then you check with your XML parser

If it's not exactly 1 without leading or trailing bytes, bail out

the biggest advantage is the simplicity of writing a client

or a library

it would then be on the same level as parsing a json payload

Have any such bugs happened in websocket implementations which have framing?

about what bug exactly are you talking? buffer overflow with websocket? i bet no client will write its websocket lib itself, the same as nobody starts to write a http lib

Or confusing 1 stanza for 2

is channelbinding data also available on websocket connections?

In theory yes. In practice web browsers won't let you access that.

But for non browser clients it'd work

ok but Gajim has nothing to do with a browser

Then it's no different than a regular XMPP TLS connection

ok so it makes sense to add a feature request with my websocket lib

For browsers I think it may be possible to use the certificate hash one (server-end-point) if the client is supported by an addon that extracts that via https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/CertificateInfo

> about what bug exactly are you talking? buffer overflow with websocket? i bet no client will write its websocket lib itself, the same as nobody starts to write a http lib Should generally be the same with low level xmpp ideally ↺

It's not though because no off the shelf XML library is suitable for XMPP

Uhm, not true?

Almost all of them have event parsing mode

But even if it were true an xmpp library should have a solution already 🙂

And almost all of them support not-XMPP XML with vulns

hi there! I've been wondering: I'm using libstrophe for a small XMPP application that I'm writing and I'm trying to add a handler for message stanzas with *NO* type. has anyone done such a thing? or will I have to determine the message type in the handler itself and then decice what to do?

cockroach: message stanzas always have a type

If there is no type attribute it defaults to "normal"

Syndace: RFC 6121 says the type attribute is optional

but yes, it defaults to 'normal'

singpolyma: sorry, I meant you

Yes. So no such thing as a message stanza with no type

singpolyma: I'm not sure about that. The RFC says "Inclusion of the 'type' attribute is RECOMMENDED"

Yes. And if it's not present then it defaults to normal

So if you mean "message stanza which on the wire happened to have no type attribute" then look for type is normal

indeed. but wouldn't that mean then I can very well get a message without the type and will then have to treat it as 'normal'?

Without a type attribute. Not without a type

exactly. but libstrophe doesn't do that - if it comes without a type, the 'normal' handler won't catch it.

right

without a type attribute

Then libstrophe is broken and you should file a bug

rgr

If there is no type attribute on the wire then the type is normal and the normal handler should definitely fire

thanks for clarifying this

is there a recovery for presence subscriptions when i lose my server and have to start new?

the remote server would not know that i lost my database, and will send me presence from people which i was subscribed

to which your server will reply "unsubscribed" so that the remote server stops doing that

but they are now not anymore in my roster, so i basically receive presence from unknown contacts

which is basically "you're screwed"

no i receive those presences

why would a server reply "unsubscribed"?

to a normal presence

lovetox, hm, indeed, the server should not reply unsubscribed, I had that wrong.

If you prepare it in advance you can probably remedy to that by subscribing to them automatically, for some time :x (keeping an eye on spam requests) ✏

i see this in my console, i get presence from all the contacts i had earlier in my roster, i am just interested as a client dev, what should i do with this, is there a way to gracefully recover somehow

if you receive unsolicited presence, that's normally "directed presence"

and shouldn't lead to automatic presence subscriptions

but in your specific case you probably want to collect those over a few days and then send out subscriptions

https://modules.prosody.im/mod_unsubscriber.html something like the opposite of this :)

In spirit. I don't know if the code helps here

or i simply show the user somehow, hey you received presence but this contact is not in your roster, would you like to add them

lovetox, I'd probably do that only if (a) the user has a very low amount of entries in their roster && (b) more than one non-contact does this in a certain amount of time.

and (c) ensure that this is not focus-stealing or anything, because otherwsie it's a great abuse vector

yeah, previously we simply showed such contacts in the roster in a group "not in roster"

lovetox, and then you can just send out type="subscribe" and type="subscribed" presences to that contact. if they still have you in their roster, their server will auto-reply with type="subscribed", otherwise they'll see a subscription request.

though type="subscribed" is not sufficient to fully restore the state; this will cause a pre-approval instaed of actually registering a subscription :|

ok now another weird issue i see

when i quit the client, i send unavailable presence out before to MUCs

basically im leaving the MUC

this presence, is reflected normally, but i dont receive it anymore because i break the connection before.

why are you explicitly leaving the MUC?

that sounds superfluous

im not sure about the details but it should not matter

if i reconnect to the server, *without stream resumption*, ejabberd sends me this unavailable presence as the first stanza after bind

that sounds like some ejabberd quirk then

I mean it can happen if the MUC takes _that_ long to send that unavailable presence out

yeah but presences are not stored for later delivery or? its not a message

but if it happens consistently even if you are offline for a longer period (say, minutes), it shouldn't.

exactly

no i just tested, i quit the client, wait 10 full seconds

reconnect, i still get the presence

but aside, don't send explict type="unavailable" to mucs on connection shutdown. your server will take care of that. ✏

lovetox, I'd take that one up with the ejabberd devs honestly.

hm my info was wrong with me sending precences, it happens when i kill the app, so nothing is sent out on quit

but then its even more weird that the MUC sends me unavailable

lovetox, are you using the same resource string as before?

and are you negotiation stream management?

(even if you don't resume)

(yes)

Shouldn't the server send unavailable presence to everything you've sent a direct presence to, when you become unavailable? (Re MUC) ✏

lovetox, if the answer to both questions is "yes", then what happens is this: - you kill the app (no proper </stream:stream> sent from the app) - the server assumes you got disconnected from the network and keeps your session around (because you negotiated stream management) - you reconnect without resuming, but binding to the same resource. the server now assumes that you don't have the SM data to resume (correctly), and has to send unavailable presence from your previous session before letting you establish the new session with the same resource. - the MUC receives the type="unavailable" resulting from the termination of the previous session and reflects that type="unavailable" correctly. - you receive that type="unavailable" because it is received by the server from the MUC after replacing your session

ah nice, so then it makes sense

i didnt know about the unavailable thing when i bind to the same resource, which is the case