Type issue leading to NotOTRMessage exception when it should have been UnencryptedError on python 3

[mathieui]

On python 3:

In context.py, the basestring type is an alias to str; however, everything in and out of the library is bytes (otherwise it does not work), so when receiving a plaintext message during an encrypted session it never enters the test for unencryptedmessage and raises a nototrmessage (which does not provoke a warning because it is supposed to be raised only outside an OTR session).

Specifically, at the end of receiveMessage, message is a bytes object and basestring is “str”.

        if isinstance(message, basestring):
            if self.state != STATE_PLAINTEXT or \
                    self.getPolicy('REQUIRE_ENCRYPTION'):
                raise UnencryptedMessage(message)

        raise NotOTRMessage(messageData)

The fix should be to change,

basestring = str

to

basestring = bytes

at the beginning of potr/context.py, it seems to work fine.

[koolfy]

Wouldn't it be confusing to leave

    isinstance(message, basestring)

when we are not testing for basestring intance, but really bytes?

Maybe it would be better to have a better named variable in there instead? Something along the lines of:

    try:
        type(basestring)
        rawMessageFormat = basestring
    except NameError:
        # all strings are unicode in python3k
        rawMessageFormat = bytes
        unicode = str

and then using:

    if isinstance(message, rawMessageFormat):

?

My concern is how having it changed to bytes accross the lib could affect other parts of the logic, and whether unicode should be left alone or could raise similar issues elsewhere? (I don't think so but we should doublecheck)

[mathieui]

If we’re testing for bytes, wouldn’t it be better to only do

rawMessageFormat = bytes

(or does that break python versions older than 2.7 that you want to support?)

[koolfy]

I don't think supporting python 2.7 and older is reasonable at this point.
Thoughts?

[tribut]

2.7 should probably still be supported for a while, but I don't think older versions are used by reasonable people any more (except in old centos releases maybe).

[azrdev]

@koolfy older is EOL afaik, but since gajim itself is on python2.7 you cannot move to python3 atm

[koolfy]

good point.

[mathieui]

@azrdev the gajim hg default branch is python3, but it’s not yet usable iirc

[koolfy]

I reinstalled a rasperry pi as an IRC client and discovered raspbian-stretch still ships python2.7 by default :)

So I guess this settles the debate, python2.7 is still very much alive, this should be fixed for 1.0.3

[azrdev]

With the release of gajim 1.0.0 last month, they finally moved to python3.
As the official wiki says, python2.x is legacy. And only 2.7 is maintained, older 2.x releases are not, as I wrote before.