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;
?OTR:AAIDAAAAAAUAAAAGAAAAwFmv0AZAqaoqNSVwPE+gaqYhgxNsekdy1T2Ql/ErhOjo3IS+0a0EUN aHbuSXK
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?
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.
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.
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…