Tails

#1 Updated by anonym 2016-01-07 13:26:03

• Assignee set to anonym

#2 Updated by anonym 2016-01-07 13:26:31

• Status changed from Confirmed to In Progress

Applied in changeset commit:53423817c3163c47e4c9ea743adfe5ab4b2285da.

#3 Updated by anonym 2016-01-07 13:27:12

• Assignee changed from anonym to kytv
• Target version set to Tails_2.2
• % Done changed from 0 to 50
• QA Check set to Ready for QA
• Feature Branch set to bugfix/10866-otr-bot-vs-unicode

#4 Updated by anonym 2016-03-29 18:10:39

• Target version changed from Tails_2.2 to Tails_2.3

#5 Updated by anonym 2016-04-13 06:50:36

• Assignee changed from kytv to intrigeri

I’ve merged stable now, so the branch is up-to-date.

Perhaps it’d be easier to test this by manually starting the bot, joining some channel and then writing a non-ASCII UTF-8 character. Preferably also try PM:ing such message encrypted and not encrypted.

Do you think you can handle it, intri?

#6 Updated by intrigeri 2016-04-15 03:22:01

• Assignee changed from intrigeri to anonym
• QA Check changed from Ready for QA to Info Needed

> Perhaps it’d be easier to test this by manually starting the bot, joining some channel and then writing a non-ASCII UTF-8 character.

If I got clearly the ticket description, you mean writing a non-ASCII UTF-8 char from another XMPP user to the OTR bot, right?

(I’m a bit confused since the commit on this branch only adds encoding operations, while I would naively expect this bug to be caused by a lack of decoding. But don’t bother, I’ll just test it, once it’s clarified what I should test :)

#7 Updated by anonym 2016-04-15 04:35:30

• Assignee changed from anonym to intrigeri
• QA Check changed from Info Needed to Ready for QA

intrigeri wrote:
> > Perhaps it’d be easier to test this by manually starting the bot, joining some channel and then writing a non-ASCII UTF-8 character.
>
> If I got clearly the ticket description, you mean writing a non-ASCII UTF-8 char from another XMPP user to the OTR bot, right?

Yes.

> (I’m a bit confused since the commit on this branch only adds encoding operations, while I would naively expect this bug to be caused by a lack of decoding. But don’t bother, I’ll just test it, once it’s clarified what I should test :)

IIRC xmpppy (developed for before python 3) works with the type unicode (e.g. that is what xmpp.Message.getBody() returns) but potr works with str (really it should just be ByteArray or something because that is how potr treats the data). Hence casting with str was my original cheap/ignorant solution, but it since that tries to encode to ASCII, python will correctly throw a fit. encode()ing to a utf-8 str is the correct way, as the proposed branch does it. We don’t have to decode() the data when feeding it back to xmpppy because it correctly deals with such things itself.

The reason we don’t have to decode is because potr is oblivious

#8 Updated by intrigeri 2016-04-15 08:44:10

• Status changed from In Progress to Fix committed
• Assignee deleted (intrigeri)
• % Done changed from 50 to 100
• QA Check changed from Ready for QA to Pass

#9 Updated by anonym 2016-04-26 09:13:59

• Status changed from Fix committed to Resolved