python-nbxmpp fails to parse a JID's domainpart expressed as an IP-literal
First off, I'm using Gajim 0.16.9 with python2-nbxmpp 0.6.1 on Fedora 27, but the relevant part appears to be unchanged in the current master branch.
The following string, which contains an IP-literal instead of an ifqdn as the domainpart, should be a valid JID according to the RFC (https://tools.ietf.org/html/rfc7622#section-3.1): ~user@[2001:638:a000:1234::ffff:56]
Such JIDs are not usually seen in the wild - but the Biboumi IRC-to-XMPP gateway maps IRC hostmasks to JIDs and may thus produce JIDs similar to the above example.
For me, this causes Gajim to frequently throw the following exception, for example when an IRC user whose domainpart is an IP-literal gets their mode changed in a channel (e.g. +o
or -o
):
13/03/18 12:34:56 (W) gajim.c.jingle Invalid JID: ~user@[2001:638:a000:1234::ffff:56], ignoring it
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/nbxmpp/dispatcher_nb.py", line 498, in dispatch
handler['func'](session, stanza)
File "/usr/share/gajim/src/common/connection_handlers.py", line 1606, in _ErrorCB
stanza=iq_obj))
File "/usr/share/gajim/src/common/nec.py", line 74, in push_incoming_event
if event_object.generate():
File "/usr/share/gajim/src/common/connection_handlers_events.py", line 687, in generate
self.get_jid_resource(check_fake_jid=True)
File "/usr/share/gajim/src/common/connection_handlers_events.py", line 79, in get_jid_resource
self.fjid = helpers.get_full_jid_from_iq(self.stanza)
File "/usr/share/gajim/src/common/helpers.py", line 932, in get_full_jid_from_iq
return parse_jid(str(iq_obj.getFrom()))
File "/usr/share/gajim/src/common/helpers.py", line 115, in parse_jid
return prep(*decompose_jid(str(jidstring)))
File "/usr/share/gajim/src/common/helpers.py", line 191, in prep
raise InvalidFormat, _('Invalid character in hostname.')
common.helpers.InvalidFormat: Invalid character in hostname.
When Gajim is launched from a shell, all this spam goes to the terminal - but when I start Gajim from the GUI, an annoying exception window pops up every time.
The above stack trace doesn't contain the relevant part of the call stack because prep
catches a UnicodeError
only to throw an InvalidFormat
. The interesting part is the origin of the UnicodeError
in stringprepare.py
:
prepare
nameprep
check_prohibiteds
All of [
(0x5b), :
(0x3a) and ]
(0x5d) are contained in the list of prohibited characters, which is the cause of the exception.
The error is triggered by the following XMPP traffic.
User discovery after joining the channel via Biboumi:
<!-- In Tue 13 Mar 2018 12:23:45 CET -->
<presence to='myself@example.org/Gajim_' from='#channel%irc.example.org@biboumi.example.org/User'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='admin' jid='~user@[2001:638:a000:1234::ffff:56]' role='moderator'/>
</x>
</presence>
Now somebody demotes User
to -o
in #channel
:
<!-- In Tue 13 Mar 2018 12:34:56 CET -->
<message to='myself@example.org/Gajim_' from='#channel%irc.example.org@biboumi.example.org' type='groupchat'>
<body>Mode #channel [-o User] by Otheruser</body>
</message>
<!-- In Tue 13 Mar 2018 12:34:56 CET -->
<presence to='myself@example.org/Gajim_' from='#channel%irc.example.org@biboumi.example.org/User'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='participant'/>
</x>
</presence>
<!-- Out Tue 13 Mar 2018 12:34:56 CET -->
<iq xmlns="jabber:client" to="~user@[2001:638:a000:1234::ffff:56]" type="get" id="123a4567-8901-2345-bc6d-ef7a8b901c23">
<vCard xmlns="vcard-temp" />
</iq>
<!-- In Tue 13 Mar 2018 12:34:56 CET -->
<iq xml:lang='en' to='myself@example.org/Gajim_' from='~user@[2001:638:a000:1234::ffff:56]' type='error' id='123a4567-8901-2345-bc6d-ef7a8b901c23'>
<vCard xmlns='vcard-temp'/>
<error code='504' type='wait'>
<remote-server-timeout xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Connection failed: connection refused</text>
</error>
</iq>
As far as I can tell, the exception is thrown as a result of the incoming iq
error response.