jdev - 2020-08-27

quien vende cc

i have some problem understanding the jid escaping

it seem incompatible with jid splitting into its part

say a user provides a string "user@host@example.com"

to use jid escaping here, i need first to know what the localpart is

as escaping must only be on localparts

but the localpart here would be, "user" incorrectly

RFC: Remove any portion from the beginning of the string to the first '@' character (if there is an '@' character present).

lovetox, the user needs to provide an escaped JID if you use that input format

JID escaping of stuff like @ is more interesting for transports than anything else

I also think that you shouldn’t allow JID-escaping @. It opens the door for fun impersonation attacks.

im trying to implement the XEP, the XEP goal is to escape userinput

not that users escape it on their own

it expicilty provides test vectors where userinput is unescaped

im asking the question now, how the XEP thinks i should escape that jid, maybe im missing something

well then, you can’t have it both ways ;)

In escaping, the hostname isn't escaped unless I'm misremembering.

you can only safely escape the localpart if you take it as separate input

So that one you can safely escape because there's no resource part.

But if you gave e.g. user@something/user@something/user@something it'd be entirely ambiguous how to escape it.

As long as it's a bare JID you're escaping, you're ok.

Kev, `user@host@example.com` is ambiguous already, isn’t it?

(the example provided by lovetox)

Kev, the JID parsing rules split on the first @ ✏

Only if I misremember about not escaping hosts.

Let me see.

Kev, no, you’re right about that

lovetox: But you're not parsing a JID.

of course, user input is a JId

No, it's not.

but is it localpart=user\40host, domain=example.com or is it localpart=user, domain=user@example.com

It's only a JID once you've done the escaping on it.

Ok Kev, how do i find the domainpart in a string that is not a JID

jonas’: But user@example.com isn't a valid domainpart.

Kev, aha!

right

so since @ cannot exist in a domainpart && you know that there is no resourcepart, you know where to split

So if you know that post-escaping it will be a bare JID, you look right-to-left for an @, and the remainder is escaped as the node

(i.e. you can waive the splitting rules in RFC6122 and rsplit instead of lsplit because of that) ✏

ok are you sure about that

did you just think that up right now?

>>> aioxmpp.stringprep.nodeprep("@foo") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python3/dist-packages/aioxmpp/stringprep.py", line 159, in nodeprep check_prohibited_output( File "/usr/lib/python3/dist-packages/aioxmpp/stringprep.py", line 116, in check_prohibited_output raise ValueError("Input contains invalid unicode codepoint: " ValueError: Input contains invalid unicode codepoint: U+0040

>_>

@ is not allowed in the domainpart according to nodeprep

Yes, I'm sure that a domainpart in a JID can't contain an @

thats not what i meant, you just described a parsing mechanism, that is nowhere described in the XEP, but seems needed to implement that

I am sure that if you are trying to escape input in order to produce a bare JID that you can do so in the manner I described, yes.

lovetox, if it’s not allowed in the domainpart (which is true) && you do not support a resourcepart in your input, then it is safe to parse from the right side

if you *do* support a resourcepart, then you cannot do that

I'm not pretending that 106 is well-written in how to practically escape stuff, BTW.

oh

Kev, we’re both wrong

the domainpart is *nameprep*, not *nodeprep*

nameprep allows @

(disclaimer: unless buggy implementation on my side)

it does only matter if idna allows @ in a domain part

I am convinced you can't have a @ in a domainpart. I could be wrong, but I am still currently convinced.

thats correct

IDNA2008 does not allow @

Kev, nothing in https://tools.ietf.org/html/rfc3491 forbids @

idna2003 seems to allow it though

luckily i dont use that then :D

bad thing that you can’t know what a domain registrar uses

lucky that userinput is mostly bare jid

but I think it’s fairly safe to assume that if someone has a domain with an `@` in it, it is going to break way more than just an XMPP client

i cant come up with a case where a user might want to specify a full jid

so I wouldn’t blame a client for breaking on that :)

(especially if "breaking" is just escaping stuff, and not segfaulting or something crazy like that)

lovetox, so go ahead

who's using @ in the localpart anyway, instead of %, # or _?

Users?

you can’t know what a user types into the JID field :)

If you're doing escaping on it, it's not a JID field, it's an arbitrary input to be turned into a JID field ;)

Kev, -fno-pedantic

Sometimes these things do matter.

(I hope this gcc-level joke comes across)

And in this case, it actually does, because if you try using JID parsing rules on something that isn't a JID ,you have pain - as shown earlier!

hm / is also not allowed with IDNA2008

so could we not do a rsplit in @, afterwards do a first encounter / split on the result

that would always produce domain and resource

then we can even support resource user input

oh damn @ is allowed in the resource

forget what i said

I think the question has to be what you're trying to have the user enter.

i think this cant be done perfectly

i can give the user a hint, that he only should input bare jids

but i cant really find out if he did that

<a.example.com/b@example.net>

not with JID escaping, indeed

without JID escaping, that is a full JID with empty localpart ✏

correct with that example, JID parsing, and userinput parsing yield different results

but i guess i can live with that :)

yeah

nobody needs to enter full JIDs manually anyways

if / where disallowed to escape

we could do split on first / then do a rsplit on @

and everything would work

and this parsing could then be used for jids and userinput

at least with IDNA2008

:)

further question

XEP says : * Note: The character sequence \20 MUST NOT be the first or last character of an escaped localpart.

but it does not say what we have to do when we encounter such a JID on the wire

because \20@asd.com is a valid JID

does that mean i have to ignore the first \20

and not convert it to a space

lovetox, not convert it is probably the "right" thing

since it would be an invalid JID otherwise

no i meant unescape it

at least the one with the least resulting damage

means "\20call\20me@example.com" -> "\20call me@example.com"

lovetox, yeah

somebody should add such evil examples to the XEP

jonas’, fyi you are missing that rule in your aioxmpp escaping code

also a client that supports escaping, is not able to generate such a jid on the wire

if the user inputs \20 at the start, it would be \5c20 on the wire

hm so that means a user in my client can’t add a contact with such a JID

thats insane, now i need an exception for that too

This XEP is highly underspecified

lovetox, this XEP is a terrible bandaid and I wouldn’t expose users to it at all

in the sense that in any place where JIDs may be used for direct input, I’d show the JIDs as they are on-the-wire

the only reason the aioxmpp implementation exists is to facilitate search and display on s.j.n, where you have a separate copy button which will copy the correctly-escaped version

i wish i didnt spend the last 3 hours to implement that

maybe i should just ignore that, and fuck the people who choose a JID that starts with \20 :D

the problem is also that there are circumstances where you don’t know if a JID is escaped or not

xmpp:call\20me@example.com

is this escaped or not?

I consider URIs to be on-the-wire

thats the only way, because consider it escaped would not be backwards compatible

hm, that would only influence how i display it

so that would be fine

so i should consider uris as escaped

and take them as is to be backwards compatible

hm maybe i should really only use this for displaying and not for input

seems safer

or i offer a button where user can disable escaping on input

hm or what if i only escape \ when there are not allowed chars in the JID

yeah if someone writes call\20me@example.com , i simply consider it escaped already ✏

that sounds like a reasonable plan

and fuck the people who mix unescape and escaped sequences in the input

why does that rule exist

that we have to escape \20 to \5c20

whats the danger when not doing that

because what if a matrix user is called yo\20life

hm in understand why i would receive \5c20

but why do i have to transform this on my userinput

im not a matrix client or a gateway

hm i guess for the same reason, when the user wants his name displayed as \20

not as space

but hard to know what the user wants here

"In face of ambiguity, refuse the temptation to guess"

hmmm its only a problem for the 10 escaped chars .. i guess when i encounter any of the 10 escape sequeneces, i have to tell the user that input expects unescaped input

that means if he wants to write yo\20life on matrix, he can put this in, but when he want to write call\20me on xmpp, he has to write "call me"

not sure if that makes sense or not

isn't that what the transport interaction XEP was supposed to solve

the more i read this the less it makes sense

Note: The character sequence \20 MUST NOT be the first or last character of an escaped localpart.

how can an addon XEP make such a rule

because that is the document which defines `escaped localpart`

(as opposed to RFC 6122 localpart)

thus, by definition, a localpart starting with \20 is *not* an escaped localpart

ok, so it means if i encounter a jid \20\27asd@example.com

i have to display it like that

and not unescape it, because its not escaped to begin with

exactly

lovetox, care to file a PR with a test case for that?

for the test vector list in the XEP

hm yeah a add it to my list

ok so its clear how to deal with it when i encounter it on the wire

still need a way to write such a JID

well, so if you encounter `\20foo` in an input, it is clear. No need to escape anything here.

if you encounter `\20foo bar` in an input, you need to escape, so you’d get `\5c20foo\20bar`

what if he wants to write the JID: \5c20foo@bar?

"run"

:D

i think i make a simple, escape checkbox, that is by default checked

Or just don't?

checkboxes are awesome

[X] Sarcasm

❎ Obviously

✅ True fact

You could probably just assume that JIDs entered by the user are unescaped and run the escape algorithm over them. Some goes in the other direction: Every JID shown to the user, e.g. in the MUC member list, is unescaped first.

flow the problem with an assumption without giving the user the choice is

that you can’t talk to some jids anymore

السلام عليكم