jdev - 2024-08-21

https://xmpp.pimux.de/file_share/70f6118c-1b33-4a9c-a9ab-7d3375b1edde/blasta_manual_xml_console_20240821-122400.png

This can be thought also as of an idea for Libervia, Movim, and other HTML based XMPP services. The idea is to make/urge people to install XMPP chat clients.

singpolyma. Does Cheogram has an XML Console?

Cheogram has no console

But prosody has a raw debug module 🙂

Real devs does that with telnet

https://github.com/movim/movim/issues/1353 Store settings in account Jabber ID

goffi. singpolyma. That might be of interest to you as well.

cal0pteryx. lovetox. And to Gajim too.

Schimon: gajims has a node browser

You can delete nodes via gui

Advanced - PEP configuration check it out

lovetox. Can you store the settings of Gajim inside a Jabber ID PEP node?

No we don't store settings

What setting are you thinking about?

This is a good idea. Suppose I use Gajim on my home computer. I install Gajim on a new machine at office or. The setting of Gajim of theme, behaviour (i.e. Show on Startup, Action on Close, Show Status Change etc.) are retrieved from PEP `xmpp:org.gajim:settings`.

> What setting are you thinking about? All the most common settings that Gajim offers, excluding Advanced. ↺

Maybe advanced too, with a warning concerning to proxy, if proxy is set to something else than default.

This was what https://xmpp.org/extensions/xep-0049.html was used for, but it fell out of favor for client settings. And https://xmpp.org/extensions/xep-0223.html is the PEP-based successor to that.

Easier said then done

Many settings are Gajims settings, but pep is per account

Would need to sync Gajims settings to multiple accounts I guess .. but not pretty

But it's complicated if different accounts have different settings

> https://github.com/movim/movim/issues/1353 > Store settings in account Jabber ID It is already the case ↺

https://github.com/movim/movim/blob/master/app/Widgets/Config/Config.php#L126

You can close the ticket

edhelas. Sorry. Thank you for the reference. I am closing it now.

Schimon https://github.com/movim/movim/blob/master/src/Moxl/Stanza/Storage.php

edhelas. It appears that you are using XML. Is that so?

No, I just serialize/deserialize a PHP array, it's purely Movim stuff, I don't need to standardize my internal settings

I could do JSON, but this was done a long time ago, "don't fix if it ain't broke".

This is the most important part that I am engaged with, this week: `$node = 'movim:prefs';`. I will see what I would do with Blasta.

Uh ?

The argument of naming nodes, that is.

edhelas. Thank you for the references. I am always happy to receive them and I think of them to be very useful.

lovetox > Many settings are Gajims settings, but pep is per account In case PEP is not available (i.e. creation of a node fails), Gajim would display a message that it can not use Jabber ID to synchronize account settings, and it would offer to contact the system administrator or switch a provider. > But it's complicated if different accounts have different settings In that case, similarly to "dot new" files of Salix and Slackware, Gajim would prompt to synchronize settings or keep them local. Psi has a similar option to group chat to auto-join "only from this computer".

Yeah lots of work for very little gain

It's not like you setup a desktop client every week on a new machine

> I could do JSON, but this was done a long time ago, "don't fix if it ain't broke". Why JSON, and not TOML? I suppose that both can be considered the same, aside from JSON which would probably be smaller due to no requirement to name "dictionary" type and allows `null` which TOML does not allow (i.e. `None` type is not allowed). ↺

> Why JSON, and not TOML? > I suppose that both can be considered the same, aside from JSON which would probably be smaller due to no requirement to name "dictionary" type and allows `null` which TOML does not allow (i.e. `None` type is not allowed). "don't fix if it ain't broke" ↺

> It's not like you setup a desktop client every week on a new machine lovetox. I agree, yet many might find it useful. ↺

> "don't fix if it ain't broke" Fine. I agree with that statement. ↺

> Yeah lots of work for very little gain lovetox. I am thinking this through. I was thinking: "What if you are connecting with Gajim on a friend's machine?". One might want to have another set of settings when he is a guest of that machine. So a profile indicator would be needed: `xmpp:org.gajim:settings:desktop`, `xmpp:org.gajim:settings:guest`, `xmpp:org.gajim:settings:travel` etc. ↺

I suggest we discuss about it on the issue tracker.

> But it's complicated if different accounts have different settings Pardon. I did not thought about it. I suppose that different directories would solve it. ↺

> Advanced - PEP configuration check it out lovetox. That browser is useflu and beautiful. More XMPP clients should gave that type of a browser too. ↺

Thank you for that browser. It is definitely helpful. ✏

Schimon: I notice you suggesting to a ton of clients to synchronize settings across clients using PEP but none of the issues you created even mentions the huge gigantic footguns this brings with it, if implemented in a naive way it'll end up causing those clients to crash when trying to log in with no remedy

Consider that the format would require both backwards *and* forwards compatibility

You need newer versions to be able to handle settings from older versions, this is relatively easy, but you also need older versions to be able to handle settings from newer versions which is damn near impossible or at least a massive footgun

moparisthebest. That is a consideration. - A crash control can be added; - The selection of settings to be stored can be limited; - A prompt dialog can be added: "Do you want to synchronize configurations?".

> if implemented in a naive way What do you mean by "native way"?

> Consider that the format would require both backwards *and* forwards compatibility If there is no compatibility, then settings stored on PEP be ignored. ↺

I do think that this would be useful.

It might be for some clients. I think the way movim does it makes sense for their case for example

Consider the simple case of logging into an ancient gajim on some Debian machine, and logging into new gajim on Arch, what's even the desired behavior? And would you want it determined by which you logged into first/last ?

yeah, thats what i meant, it starts like a naive idea, hey store some settings there in the pep node

> No, I just serialize/deserialize a PHP array, it's purely Movim stuff, I don't need to standardize my internal settings edhelas: how do you handle different movim versions? (Or if PHP can (de) serialize differently by PHP version, how is that handled?) ↺

and then you work a year to iron out all edge cases and bugs

100% that lovetox , and it's unclear to me what the desired behavior even should be

>> if implemented in a naive way > What do you mean by "native way"? No https://www.wordnik.com/words/naive ↺

> No https://www.wordnik.com/words/naive Pardon. I read it differently. ↺

> and then you work a year to iron out all edge cases and bugs Gentlemen. It can always be a "development" feature that can be tested on a span of years and only after it has been tested, you can offer it as a feature. ↺

>> Consider that the format would require both backwards *and* forwards compatibility > If there is no compatibility, then settings stored on PEP be ignored. Ok but then is it useful? I would imagine under normal circumstances users will almost always end up using different versions of the same client, if this can only sync settings between identical versions it's useless ↺

This is how settings are stored on PEP node `xmpp:blasta:settings:0` of every JID which interacts with the Blasta system: ``` <item id="routine" xmlns="http://jabber.org/protocol/pubsub"> <value>private</value> </item> <item id="enrollment" xmlns="http://jabber.org/protocol/pubsub"> <value>1</value> </item> ```

My point is it's easy to say "sync'ing settings would be nice and should be implemented!" (fwiw I agree it'd be nice) but it's far from simple and all the requirements (*especially* for edge cases) need ironed out before you can even think of a design

Schimon: and how does blasta implement backwards and forwards compatibility ?

I do not know. I jhave only implemented it for the first time, 30 minutes ago.

I suppose I will use the digits as versions `xmpp:blasta:settings:0`, `xmpp:blasta:settings:1` etc.

Right, the naive way I mentioned that will shoot you in the foot later 😞

Blasta does not have many settings yet. I doubt Blasta would even reach to ten (10) settings. ✏

Ah, version number: so then you run v1 and it migrates settings from v0 once and you change some things and go back to v0 (maybe v1 breaks your workflow somehow) and those changes aren't there! So you make the changes again in v0 and keep using it and making changes for a year then v2 comes out which fixes your workflow so you upgrade and it migrates your settings from v1 so you've lost a years worth of settings !!!!!

Then download those settings to file and inform the men who uses it.

And the settings that Blasta offers are afew. In any case that settings are not reachable, it will default to regular settings.

> Then download those settings to file and inform the men who uses it. What version downloads which settings to a file ? ↺

> edhelas: how do you handle different movim versions? (Or if PHP can (de) serialize differently by PHP version, how is that handled?) https://www.php.net/manual/en/function.serialize.php ↺

There since PHP4

And what I'm actually handling is an array, the syntax didn't changed for something like 20 years

An array of what though?

> If you need to unserialize externally-stored serialized data, consider using hash_hmac() for data validation. Make sure data is not modified by anyone but you.

I'm just gonna leave that here

Yea PHP unserialize will totally run arbitrary code and is unsafe to use on untrusted input...

you're in a real pickle with that one if you feed it untrusted input

No that's python 🤣

:D

(for context that's an absolutely terrible joke about https://docs.python.org/3/library/pickle.html )

hey!

edhelas: hey can't I log into my server with your movim ? Which means I can set malicious settings which will run code on your server as your PHP process? 💀

> What version downloads which settings to a file ? moparisthebest. Currently, there is only one version of both. ↺

Schimon: right but planning for the future...

> Yea PHP unserialize will totally run arbitrary code and is unsafe to use on untrusted input... This is an issue. The settings are store on JIDs, which means that people can set anything they want, and Blasta must consider a situation of malicious code. ✏ ↺

Grep finds 18 calls to unserialize() in movim, I don't know about the rest yet but I'm 99% sure https://github.com/movim/movim/blob/master/src/Moxl/Xec/Action/Storage/Get.php#L23 is vulnerable to anyone running arbitrary code on any movim instance edhelas ! Unfortunate to discover this publicly but the cat is out of the bag now

moparisthebest. Blasta already usese two settings: 1) Enrollment (opt-in or opt-out) which has a single character. So length must be checked and be one. ``` <item id="enrollment" xmlns="http://jabber.org/protocol/pubsub"> <value>1</value> </item> ``` 2) Preferred node (private, public, read). I suppose a single character would also be good. ``` <item id="routine" xmlns="http://jabber.org/protocol/pubsub"> <value>private</value> </item> ``` Could or would this (value as a single character) prevent the danger of malicious code?

> Grep finds 18 calls to unserialize() in movim, I don't know about the rest yet but I'm 99% sure https://github.com/movim/movim/blob/master/src/Moxl/Xec/Action/Storage/Get.php#L23 is vulnerable to anyone running arbitrary code on any movim instance edhelas ! > > Unfortunate to discover this publicly but the cat is out of the bag now I know, the rest is internal DB stuff ↺

edhelas: even the 'headers' in app/Upload.php ? Not user supplied ?

Also attributes like 'prekeys' sound suspiciously user-server-supplied

moparisthebest Please ensure to explain all the details in this public channel ✏

Yea sadly it was too late once jonas’ mentioned that... We can avoid making public (searchable) GitHub issues etc until a fix is published though, probably best that can be done

Might want to turn off your public movims and maybe message other big instances if you can...

I honestly did not expect this fallout.

I don't write PHP and even *I* knew that unserialize on untrusted data is a terrible idea.

apologies.

Who did... If Schimon hadn't brought up sync'ing settings it could have been undiscovered for many more years...

I've got no PHP experience, but wonder if static analyzers could pick up on stuff like this. That might be a handy check to add, somewhere.

Guus: do you do any deserialization in Java on untrusted data? Another common place these RCEs pop up :'(

For years the json deserializer of choice in javaland was Jackson, which had the unfortunate default of being vulnerable to RCE on untrusted input, dozens of CVEs at least while they kept adding ever more classes to the blacklist

moparisthebest: I'm sure that's possible, although I don't think it's as easy to have something deserialize and automatically execute stuff

iirc at some point they changed the default, but it's still a ghost

Guus: it's very easy, Jackson's default was to support specifying class names to instantiate with reflection, and there are tons of classes you can create that way that'll run arbitrary code

URLClassLoader is the easiest example

sure

That's roughly the same way the unserialize (PHP) and pickle (python) vulns work too

the log4j stuff was similar, right?

Haha yes, good times good times

I think that went through JNDI or something

like you said, ghosts.

I quit my Java dev job for a Rust job literally 1 week before log4j hit the fan, best timing of my life

Maybe the best is to actually make a small custom XML, at least the parser will do the job 🤔

just use XEP-0004

I don't care what the problem is, XEP-0004 is the solution!

This serialize/unserialize thing wasn't touched since almost the beginning of the project

But 0004 was already there 😱 !

If I have to fix it, Lets Fix It Properly ™

As long as you don't have the wrong settings on your XML parser and enable billion laughs etc 🥲