Core Apps » KeySync

I'm terribly pretentious, so I use Sanskrit (in unicode Devanagiri) for my XMPP resources. Now, ordinarily, an entry in ~/.purple/otr.private_key starts like this (I created this by transliterating to roman script):

(account
(name "darael@jabber.org/dhumabha")
(protocol prpl-jabber)
(private-key
(;blah blah blah


However, the equivalent entry using ????? (the Devanagiri representation) as the resource results in something quite different:

(account
(name #64617261656C406A61626265722E6F72672FE0A4A7E0A582E0A4AEE0A4BEE0A4AD#)
(protocol prpl-jabber)
(private-key
(;blah blah blah


That name gets interpreted by the keysync as a value not of type "string", which is usual, but of type "long". As a result, when otr_private_key.py:parse tries to call the method "find" on it (if element[1].find('/') > -1: on line 82) the whole thing blows up (because there's no find method on a long, while there is on a string).

While it wouldn't be unreasonable to argue that pidgin-otr is what's broken here, in that it's doing something funky when it notices unicode values outside ASCII space rather than just saving otr.private_key as a unicode text file, the immediate fix is to have the keysync parser decode whatever the otr plugin is doing to those unicode names if it detects their presence (which should be relatively easy; they are delimited by # rather than " so they're distinguishable from "proper" strings but finding their beginning and end is just as easy as for a string). Strictly speaking, these ought then to be processed by the three relevant profiles of [STRINGPREP] (see the XMPP Address Format RFC), but doing that is arguably the responsibility of the client. Still, it can't hurt, right?

A workaround is, of course, to switch to the transliterations using the ASCII set.