powered by Jive Software

OTR Plugin for Spark Client 2.6.3

I have Openfire(3.8.2) and Spark(2.6.3) running smoothly and we’re doing some tests before rolling it out to other departments.

I’m having trouble with one thing… users are experiencing “being OTR’d”… we get random messages of characters such as;
hrWnhaN816bV6x6DxLL8L59RobNrrMt8jXFWguqabtYCwf2ccXlAFlnn87yN6OJoeoLylUqLaR6Jk61 CpvukbelSJ3+d
H3q83orZM3FIHIKzIny2mdqVNbTpBtWUJqJOGQImC/ElqgLfSLm5cyjPj3uphC939UpEiXh7QXqMb9i JaVH4vLoim
… and so on.

Why is it happening? Is there a way to stop it that doesn’t require removing the OTR plugin?

Is it simply because one side of the chat has the OTR on and the other doesn’t?

1 Like

your last sentence is likely. if a user has a chat open, then clicks the OTR button, it should prompt the other user… but, the text you posted above does look like it’s been encrypted by OTR at least on one side. If you have the monitoring plugin setup on Openfire, and you check the Archived conversations, an OTR conversation between two users looks similar.

I just did a test. I had a chat open where we both accepted the OTR.

The other end kept their session open while I closed mine and had them send me a message. The message that they sent was “encrypted” gibberish;


So it seems that if you establish OTR with someone, close the window then they message you again in the original window - their FIRST message will be sent as gibberish but the rest of the conversation will go on as normal and OTR will still be on.

If you both close the window with OTR on, the first message sent again is still gibberish. Apparently you have to fully unlock the conversation completely to not get the OTR message on either side. This is silly - users are going to be confused as to why this is happening. I guess I’ll have to make the decision wether or not to remove the plugin or be up to answering a million questions from people.

hmm… could be a bug in the OTR plugin.

I’ve opened a ticket for this: SPARK-1569


Hi, I am encountering the same problem and I suppose it is a BUG.

However, I have found a temporary solution for this BUG and share to you:

Spark-Preference-OTR Messaging-Select ‘Close OTR session when chat window is closed’

After some testing i can confirm there is a bug, or two. But it is caused by some other thing. I have changed the description of the ticket SPARK-1569.

In general, there is a problem in Spark when no chat windows is opened and it receives a new message through already established OTR session. The first message will be gibberish as OTR module is not loaded at that point. It is only loaded if you open the chat window before getting the message. Some racing condition bug which also causes this SPARK-1548.

Your workaround will only work if the starter of OTR session closes the window. When the other side closes the window OTR session is still not closed.

As we have no active Spark developers and OTR sessions is rather complex thing, i doubt this will be fixed anytime soon…