OTR: Investigate what the check for IRC action in OTR.jsm onSend is supposed to do
Categories
(Chat Core :: Security: OTR, task)
Tracking
(Not tracked)
People
(Reporter: KaiE, Unassigned)
References
Details
File OTR.jsm
onSend(om) {
... // check for irc action messages
if (om.action) {
om.cancelled = true;
...
What is this code supposed to do? And does it work?
Reporter | ||
Comment 1•6 years ago
|
||
I would appreciate some help with the analysis on this bug, maybe from someone knowing the chat code well?
The question is, what does this code do, does it make sense, can it be improved?
Comment 2•6 years ago
|
||
I think it is supposed to do something like handling proper encryption of action messages on IRC (e.g. when you type "/me waves", this gets sent as ACTION\001waves\001
, then other people's IRC client's display that as "* clokep waves*".
It looks like this code is trying to send this as /me waves
directly though. I don't really know why though. Maybe arlo remembers?
At the very least I think we need to add some comments explaining what's going on here!
It looks like this code is trying to send this as /me waves directly though. I don't really know why though. Maybe arlo remembers?
Here're a bunch of relevant links to IRC command handling,
https://github.com/arlolra/ctypes-otr/issues/3
https://github.com/arlolra/ctypes-otr/issues/41
https://bugzilla.mozilla.org/show_bug.cgi?id=1139203
https://github.com/mozilla/releases-comm-central/commit/293693fdb9d0477fa18340f5d263927b38daa5b9
https://github.com/arlolra/ctypes-otr/commit/7afd82c172b666c9b45af4b69177725c5fca2557
https://bugzilla.mozilla.org/show_bug.cgi?id=1138689
https://github.com/mozilla/releases-comm-central/commit/631a4702a1583eaf22bdfe38052c18b6d323f53e
The crux of the answer starts in 1138689#c9
Basically, if the OTR extension is enable and the action command is used, it cancels the command but sends the action contents encrypted as a normal message with a prefix of "/me ". This avoids bypassing encryption while also taking into account that the receiving end probably isn't hooked into decrypting actions it receives. Most clients' UI, including Thunderbird/Instantbird, do the right thing with the inline prefix. See the links to the relevant discussion on otr-dev in 1138689#c12
Hope that helps
Updated•5 years ago
|
Updated•2 years ago
|
Comment 4•7 months ago
|
||
I think the initial question was answered and our OTR code still handles /me
in that way.
Description
•