Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#7053 closed defect (fixed)

messages lost due to e2e encryption

Reported by: chrysn Owned by:
Priority: normal Milestone: 0.15
Component: None Version:
Severity: major Keywords:
Cc: Blocked By:
Blocking: OS: All

Description

Bug description

when using end to end encryption, messages got lost and these exceptions showed up:

(see attachment)

for lack of direct access to the other end, i can't give details on what it looked like there.

e2e authenticity was established, both ends use gajim-0.16beta

Steps to reproduce

can't tell, just happens. the first exception potentially came up after i disabled e2e for the main account.

Software versions

OS version: Debian GNU/Linux sid/experimental
GTK version: 2.24.8-2
PyGTK version: 2.24.0-2

Attachments (2)

bt2 (1.9 KB) - added by chrysn 5 years ago.
exception backtrace
bt1 (1.9 KB) - added by chrysn 5 years ago.
exception backtrace

Download all attachments as: .zip

Change History (9)

Changed 5 years ago by chrysn

exception backtrace

Changed 5 years ago by chrysn

exception backtrace

comment:1 Changed 5 years ago by chrysn

errata: the versions affected are 0.15beta2, not 0.16beta2. the msg_id excption is the one that potentially came after disabling.

comment:2 Changed 5 years ago by asterix

I already saw those TB too, but I'm not able to reproduce when I Want :/

How did you disabled E2E? in advanced options? which options? in chat window by unchecking the "Toggle E2E encryption" checkbox?

I guess you cannot reproduce the TB when you want?

comment:3 Changed 5 years ago by chrysn

i disabled e2e using the advanced options (enable_esessions set to deactivated for that account). the chat stayed encrypted telling from the icon; the icon went away when i closed and opened the chat.

i'm going to re-enable it for partners i can afford to lose messages with and with whom i can debug it.

in the meantime, i had a quick look at the code in connection_handlers_events; besides HelperEvent? being old-style object (which, as far as i am informed, is calling for trouble), i found that thw show_in_roster attribute gets set unconditionally in generate(), while msg_id would have to be assigned from outside (not accessed in DecryptedMessageReceivedEvent?'s functions). we'd need to find out where those incompletely instanciated objects come from.

comment:4 Changed 5 years ago by asterix

what do you mean by old-style object?

msg_id is set in session.py. And as all message should be in a session, all messages should go through the decrypted handler in session.py. It seems (if the tb occures) that some messages don't have a session, that's what I'd like to understand.

Having the XML that causes this would help, but as it's hard to reproduce ...

comment:5 Changed 5 years ago by Yann Leboulanger <asterix@…>

  • Milestone set to 0.15
  • Resolution set to fixed
  • Status changed from new to closed

(In [13311081f390]) prevent traceback. Fixes #7053

comment:6 Changed 5 years ago by Yann Leboulanger <asterix@…>

(In [74445e12a604]) prevent traceback. Fixes #7053

comment:7 Changed 5 years ago by chrysn

thanks, trying it out now.

to finish up on the old-style object issue: since around python 2.3, you create classes by

class Foo(object):

instead of

class Foo:

even if you don't inherit from anything particular (old style classes are still there for compatibility reasons). i don't expect problems to show up here 'cause the objects won't be mixed with exceptions or integers, but it's generally bad practice to still use them these days.

Note: See TracTickets for help on using tickets.