jdev - 2022-02-09

How do I specify something that's still very much in use, when the document has evolved and this thing I want to specify "doesn't exist anymore" on paper but is still pretty much everywhere in practice

(oldmemo)

do we do Historical for those?

In particular, omemo vs pubsub#type

It's not historical

Is it

Historical might still technically be for things invented prior to the [XJ]SF and [XJ]EP procedure existed, but I'm thinking it could be used for things developed outside of the XSF and that would be good to have a stable reference for

to document "this is a thing that some software are doing"

I'd say my case also doesn't fit in there, unless you want me to do the thing first, make it a de-facto standard that everybody will rant about, and then come back with it

For O(LD)MEMO that was done as a version so that it went into the attic, tho that seems like a weird thing

Or did I misunderstand the whole thing?

pep., put it in the omemo xep?

"This is your brain on meetings"

jonas’, the eu.siacs ns isn't a thing anymore

In the spec

welp

Link to https://xmpp.org/extensions/attic/xep-0384-0.3.0.html

Can I branch 0384-0.3.0? :P

See, perhaps it should have been a Historical XEP?

yes

Are we allowed to modify hysterical xeps? ✏

is it worth the hassle to write even down what you intend to write down?

I was kinda asked to "because it's not specified" :/

so just don't do pubsub#type for omemo?

then it doesn't have to be specified :)

just migrate to newmemo

Yeah in 10 years

*shrug*

Anyway, it's interesting to know that there's no answer to this

the OMEMO spec history is really unfortunate

understatement?

I think it would be the same with any other(?) if you change/update the NS.. I guess there could be a note in the spec like "In an earlier version of this spec blah blah, you can do this and that"

("update" also meaning ":0" -> ":1" to me)

(it's not the same ns anymore)

implementation note?

Yeah

I'll fill something for that. Waiting to be shutdown somewhat..

Also, I'm wondering if it's written anywhere (or should be written anywhere) to prefer purging nodes instead of deleting them

So that doesn't ruin the work/expectations of other clients. Say I start filling pubsub#type on my nodes and somebody comes in, yanks everything and recreates the node without the field. Unless obviously that's on purpose

I'd say other clients need to be able to deal with nodes not containing pubsub#type ✏

Sure, that's not my point

it seems a bit futile in putting energy in polishing oldmemo that way then

Just that it'd kinda ruin the effort a client puts in

This doesn't just apply to OMEMO

It applies to everything pubsub

Am I the only one seeing this as a generic issue? (purge/delete)

I don’t think I’ve ever seen it being an issue.

Maybe it is for OMEMO, which I don’t use.

But for everything else PubSub, clients do the sensible thing.

Let's forget about OMEMO for a sec, that's not the point

I should have waited 24h before I started another topic

Link Mauve, and hmm, I do remember some devs discovering purge (gajim?) and being happy that it exists and that it can be used instead of delete. Might have been for avatars or the like, I don't remember the details

Say for privacy settings and whatnot

So if this dev didn't know about this, I don't want to imagine how many people getting into XMPP don't either.

pep., I just refused (deferred) to follow your topic change. You would've gotten the same comment if you hadn't written the other line.

That doesn't answer my question really but ok. Link Mauve does, but I'm not sure I agree that clients "just do the sensible thing" (I have an example with gajim -- I can find logs again -- and gajim is not any client)

Or when gajim also used to reset max_items to 1, clearing microblog nodes. Or something similar

Mistakes happen, surely, but it'd be nice to guard against them somehow

Would that fit modernxmpp btw? (or anywhere else?) Or will this just live as tribal knowledge

Yes, more information in the implementation notes + Appendix H: Revision History. Change namespace to urn:xmpp:omemo:1 -> Change namespace from eu..... to urn:xmpp:omemo:1 This would be very helpful.

other than gajim and pidgin, is anyone aware of other clients using _xmppconnect ?

don't you have the same issue with the http lookup method?

no because https

ahh, yes

luckily, smack appears to only implement the http lookup method, and not (yet) _xmppconnect

does it enforce https when doing the lookup ?

I suppose there's not much point in adding _xmppconnect checking support to prosodyctl then

because indeed you can't trust it with regular http either

Isn't that mandated by whatever defined /.well-known/host-meta ?

Beware HTTP redirects tho

not much is because this was in those young carefree days when non-TLS was ok!

the websocket rfc does say: > Thus, the connection endpoint is still authenticated, and the delegation is secure as long as the Web-host Metadata file is retrieved via HTTPS.

sooo, what does this mean, we should not use the dns method?

lovetox, well, do you enforce DNSSEC for it now? and how do you validate the certificate ?

and which if any domain do you send in SNI

I expect the answer to be "the websocket library takes care of this" in which case you are vulnerable to MITM

of course we pass the library just the url

there is nothing more to configure

except the protocoll "xmpp"

i could implement the https method, but makes everything again more complicated

lovetox, so right now if _xmppconnect.example.org pointed to wss://evil.com/xmpp and evil.com presented a valid cert for evil.com you'd just trust it and go on ?

I mean that's what I expect, but it's vulnerable to MITM :(

yes

it's only ok with DNSSEC, so I think I'm going to propose removing the DNS method alltogether from that XEP

yes, i dont see how any websocket library will support this

Tho cache poisoning attacks isn't _that_ easy to pull off

if you go https, which of the 2 methods would you pick? XML or json ?

(or both?)

json

I unfortunately also think that's more sensible

because python, and json maps to python dicts

:)

well and which do you think 100% of web clients pick? :/

I think I'll also propose getting rid of the XML method and see how that goes :P

in the short term you might want to disable DNS websocket discovery to avoid mitm :/

wonder what pidgin does and how to get ahold of them...

xmpp:devel@conference.pidgin.im?join

didn't expect that

i also checked another python websocket lib, they also dont support this

tls is always verified against the uri

lovetox, note that the JSON method is optional, and the RDF one is mandatory.

my rust websocket lib lets me pass in an already open+validated TLS connection, so I *can* validate against the proper domain

So some servers (such as JabberFR’s) only provide a RDF file.

but no web servers support this

which is a bigger problem

ugh it's true https://datatracker.ietf.org/doc/html/rfc7395#section-4

yeah then i will use xml

i will not do 2 https requests

(pipeline?)

hm i abstracted that pretty good away, i can easily exchange the dns discovery for a https disovery

and push this as a security update

nice!

oh no, tigase probably supports it, any tigase devs about? https://github.com/tigase/tigase-http-api/blob/2346fb8d4f7adf09707554dc16976f8e87f77548/src/main/groovy/tigase/http/modules/dnswebservice/DnsResolver.java#L168

adium...

https://github.com/search?p=3&q=_xmppconnect&type=Code if anyone wants to help :)

Wojtek, or try xmpp:tigase@muc.tigase.org?join maybe

oh no https://github.com/xmppjs/xmpp.js/blob/63aecc49157980f6d68cc58605cf8a3fef664a2a/packages/resolve/lib/dns.js

DoH?

14 years ago, maybe it's not being used? :crosses-fingers: https://github.com/HSSANN/jabber-net/blob/1b4e73417523426e854dd97b1b73ebc7e2876f0f/jabber/connection/HttpStanzaStream.cs

99% of the github search results are libpurple

purple clones?

active on the play store https://github.com/BombusMod/BombusMod/blob/6672861668979fb3612ea5933d437f68c1df4931/src/main/java/io/DnsSrvResolver.java

it's mostly libpurple forks or copy/pasted into various clients and/or adium forks etc

can one have a cert which is valid for 2 domains, as in a.org and b.org?

yes

yes

subjectAlternativeNames can contain any number of identities

ok, i knew wildcard, and subdomains, but was unsure about completely different ones

:)

you can put a video of you playing with your cat in there

what in the world https://github.com/poVoq/converse_wp/blob/5df09d931fb5b70a0fd854a006c5623240677aeb/conversejs.php#L140

lovetox, but SNI only lets you request a cert valid for 1 domain, which is fun

active project https://github.com/JustOxlamon/TwoRatChat/blob/8f75fa37f84367d7bc0fe9b61e0ff3554eda8c58/JabberNet-2.1.0.710/jabber/connection/HttpStanzaStream.cs#L107

no one has confirmed in pidgin muc yet, but looks to me like it supports BOSH only and is indeed vulnerable to mitm https://keep.imfreedom.org/pidgin/pidgin/file/tip/libpurple/protocols/jabber/bosh.c#l97

unfortunately that looks like the biggest attack surface :'(

(making at least pidgin, adium, chatty, thunderbird, and what else vulnerable ?)