Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Private messages cease to function if a user's internet drops without their client crashing #64

Open
ghost opened this issue Mar 19, 2019 · 0 comments

Comments

@ghost
Copy link

ghost commented Mar 19, 2019

Problem:

Private messages cease to function if a clients connection is killed by the server, but they do not get booted back to the login screen. The user attempting to message the flickering nickname will be referenced as User A. User A attempting to private message the flickering user, referenced as User B, will be able to send messages, but they will not be received by User B.

User A will see User B disconnect, and then immediately reconnect. User B will not see any disturbances on their client. Any private message history will be lost to User A, as the flicker creates a new buddy under the same nickname. User B will retain their chat history. Neither User A or User B will be able to continue exchanging messages until one of them exits the client and then re-enters.

Reproducing:

Create a room with two users. Have User A running version 2.5.7 of Cryptodog. Have User B run any version 2.5.6 and below. Have either user send a private message to the other. Wait until the server closes User B's connection. You will know this has occurred when User A sees User B disconnect and then instantly reconnect on User A's client. Attempt to send a private message on either client.

Ramifications:

Users with unstable internet may find themselves unable to receive private messages, with no indication that this issue has occurred. This bug is not limited exclusively to outdated Cryptodog clients, but will occur if a users connection is interrupted, but their client remains logged in.

Potential causes:

OTR key exchange re-occurs on User A's side, but User B's client believes it has already occurred, and does not re-exchange keys.

Potential fix:

Simple: boot User B client-side on disconnect
Complex: alter OTR exchange to re-occur if a client indicates that the other has disconnected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

0 participants