selurveduZash, thanks for your reply. I have not read https://datatracker.ietf.org/doc/html/rfc3490 very carefully, and while I don't see any direct reference to space characters, it seems to only permit the letters, digits and hyphen-minus characters . Is that what you meant?
ZashSorry, I don't have this swapped in right now.
selurveduZash, ah, that's Re: is " " a valid domainpart?
ZashThis topic hurts my brain, I don't wish to swap it in right now.
selurveduThat's fine, I'm pretty sure you pointed me exactly in right direction.
selurveduIf so, that means idna_verify() in https://github.com/dino/dino/blob/master/xmpp-vala/src/module/jid.vala#L77 is missing a bit.
ZashnameToASCII_UTF8() should deal with it
ZashThat's the thing in Prosody that deals with it.
ZashSo presumably it doesn't behave differently when called from a different application :)
Zashhttps://hg.prosody.im/trunk/file/1cac469b18d0/util-src/encodings.c#l351 same default, but + STD3 rules, whatever those were
selurveduZash, did you say `@` is a valid JID in Prosody? I did not quite get that part where you mentioned it on Saturday
ZashI may have said valid JIDs had a shockingly large overlap with valid hostnames.
selurveduah, that's what you meant, the https:// hostname thing
Zash`dig https://www.zash.se txt` and be horrified
selurveduAh, that's completely normal for TXT, isn't it? :)
Zash"https://www" is a valid DNS label.
selurvedu;; QUESTION SECTION:
;https://www. IN A
;; ANSWER SECTION:
https://www. 0 IN A 127.0.13.37
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
Right, works with dnsmasq
ZashSince / separates the resource part from the bare JID, it can't be part of username or hostname. But at the same time, it can be part of the hostname. And now my IDNA headache has returned. Thanks a lot!
selurveduYou're welcome! 😁️
ZashSo if you only apply hostname validation to a hostname, a / could get past. And also @
ZashAnd then you can have a full jid as hostname
ZashAnd then your head will hurt
ZashIf I don't finish this modernxmpp text I was writing then I'm blaming you!!!!111eleven
selurveduSure, I don't mind if you do :)
selurveduHmmm... A full jid with a domainpart being a full jid with a domainpart being [recursion]
selurvedu> So presumably it doesn't behave differently when called from a different application :)
"Well... It doesnt...", I thought as I saw this:
(Din0:1124301): xmpp-vala-DEBUG: 18:08:35.508: jid.vala:78: idna_verify(" ")
(Din0:1124301): xmpp-vala-DEBUG: 18:08:35.508: jid.vala:83: nameToASCII_UTF8 status = 0
"Unless there's a missing bit just like I suspected".
I looked at the code you linked to, and the only difference I could spot was the one you mentioned, "+ STD3 rules, whatever those were". I went to find out what these are.
The IDNA RFC mentions "STD 3" in the references section and refers to it in the "LDH label" section. /usr/include/unicode/uidna.h describes UIDNA_USE_STD3_RULES=2 as "Option to check whether the input conforms to the STD3 ASCII rules, for example the restriction of labels to LDH characters (ASCII Letters, Digits and Hyphen-Minus)."
So this was a missing part indeed. The validation works as intended now.
selurveduZash, thanks a lot for your help! You saw the root of it right away.
selurveduFor some reason I'm getting U_STRING_NOT_TERMINATED_WARNING and U_BUFFER_OVERFLOW_ERROR errors now (which are safely ignored, but they shouldn't happen in the first place, so this needs further investigation), but that's obviously a completely different issue unrelated to XMPP and domain names.