jdev - 2021-09-06

Zash, 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 [0][1]. Is that what you meant? [0]: https://datatracker.ietf.org/doc/html/rfc5890#section-2.1 [1]: https://datatracker.ietf.org/doc/html/rfc5890#section-2.2

Sorry, I don't have this swapped in right now.

Zash, ah, that's Re: is " " a valid domainpart?

This topic hurts my brain, I don't wish to swap it in right now.

That's fine, I'm pretty sure you pointed me exactly in right direction.

Great

If so, that means idna_verify() in https://github.com/dino/dino/blob/master/xmpp-vala/src/module/jid.vala#L77 is missing a bit.

nameToASCII_UTF8() should deal with it

That's the thing in Prosody that deals with it.

So presumably it doesn't behave differently when called from a different application :)

https://hg.prosody.im/trunk/file/1cac469b18d0/util-src/encodings.c#l351 same default, but + STD3 rules, whatever those were

Zash, did you say `@` is a valid JID in Prosody? I did not quite get that part where you mentioned it on Saturday

no

I may have said valid JIDs had a shockingly large overlap with valid hostnames.

ah, that's what you meant, the https:// hostname thing

`dig https://www.zash.se txt` and be horrified

Ah, that's completely normal for TXT, isn't it? :)

"https://www" is a valid DNS label.

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

Since / 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!

You're welcome! 😁️

So if you only apply hostname validation to a hostname, a / could get past. And also @

And then you can have a full jid as hostname

And then your head will hurt

If I don't finish this modernxmpp text I was writing then I'm blaming you!!!!111eleven

Sure, I don't mind if you do :)

Hmmm... A full jid with a domainpart being a full jid with a domainpart being [recursion]

https://cerdale.zash.se/s/bBRHmrR71ZkNw47r/ffabd2e5-d83e-46cc-a3c9-ca62c6939a2c.png

XMPP ...

😹️

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

Zash, thanks a lot for your help! You saw the root of it right away.

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