send "the following was not encrypted" messages during OTR from the respective user

[mcnesium]

sometimes otr sessions do not work well because of whatever reasons. in the main window root will then say something like:

<@root> otr: The following message received from user@server.tld was not encrypted: [-unencrypted-message-]

it would be a blast, if those messages would not come out in the main window, but open a new query window for that user, just like any other query does. this would be good for a number of reasons:

if i am not on the computer or busy chatting in some other window, i might not see this message and cannot answer the call, and the message would scroll away unseen.

a new created query window will blink or hilight or just be there to be recognized, whenever i get back.

also the line might have important related content to further chats, that come up if i do see the message and open up a query window myself. the content will be missing in the logfile of that chat, because its in the logfile of the main window.

i am aware that an unencrypted message from an assumed trusted buddy might be considered as an attac of a third party. but even if that is the case, the content of the message is wrapped by the error message and therefore can be identified as a potential thread.

(normally, if the user sends a second line, before i answer, this would then be encrypted and brings up a regular query window, so only the first line is missing).

[anonymous]

Can confirm this bug with:

bitlbee 3.0.1-2
bitlbee-plugin-otr 3.0.1-1
irssi 0.8.15-4

on Arch with Kernel 2.6.37.

[blueyed]

Just for reference, since I have just looked at the source of bitlbee and libotr regarding this.

The error gets generated by libotr which then calls op_display_otr_message (in otr.c; via ops->display_otr_message).

This then uses irc_usermsg to display the OTR message. I am not sure if this function is meant to display messages in query windows (according to the "private" setting) - I could only find use of the "private" setting with bee_irc_user_new (in irc_im.c).

[drewskiwooskie@…]

I get the same thing: bitlbee 3.0.2 libotr 3.2.0 on CentOS with irssi/xchat

[praseodym]

Same problem here with 3.0.3 on Debian.

[pesco]

#767 is a duplicate of this. quoting myself from there:

IIRC, this problem appears because it is really libotr producing the message via a generic callback. confirm severe annoyance. need to investigate whether there is some magic we can perform to win control over these messages and route them the right way.

[pesco]

ok, had a look. TODO:

1) factor the function to message the user from a specific irc nick (via query or control channel, as appropriate) out of bee_irc_user_msg (irc_im.c).

2) we get the username in question as an argument to op_display_otr_message. we need to turn that string back into the right data structure and call our function from 1).

[pesco]

1) new function: bee_irc_msg_from_user (irm_im.c).

2) easily done with existing functions.

revisions 814 and 815 in ​http://code.khjk.org/bitlbee/. please pull.

[pesco]

actually, i'm not happy with this because it allows the other party to spoof messages from libotr. it shouldn't be a problem if they say "this was unencrypted", but there are other cases where the respective function is used that might be more severe. for instance it might be possible for an untrusted attacker to make it seem like the connection was refreshed due to some condition and is now trusted.

in the same vein, i'm contemplating pulling the message coloring code completely. the coloring can be trivially spoofed, and a user might neglect to pay attention to the authorative statements by root in the control channel.

one idea that came to my mind was to use ACTIONs ("/me") but then we would have to disable the current behavior of converting an in-band /me to them.

is there any other type of IRC message that would be delivered to the right window (query or channel), ideally cause a hilight, and be clearly distinguishable from in-band messages??

[pesco]

Replying to pesco:

actually, i'm not happy with this because it allows the other party to spoof messages from libotr.

[...]

one idea that came to my mind was to use ACTIONs ("/me") but then we would have to disable the current behavior of converting an in-band /me to them.

is there any other type of IRC message that would be delivered to the right window (query or channel), ideally cause a hilight, and be clearly distinguishable from in-band messages??

NOTICEs would be another candidate. at least irssi delivers them to the same window as it would a PRIVMSG but displays them distinctly different. is it the same for other IRC clients?

a problem with NOTICEs is that [at least in irssi] they aren't logged while away and don't trigger a hilight of the window.

[pesco]

Replying to pesco:

a problem with NOTICEs is that [at least in irssi] they aren't logged while away and don't trigger a hilight of the window.

this can be mitigated by setting a hilight on "The following message .* was not encrypted:".

[pesco]

revision 816 and 817 at ​http://code.khjk.org/bitlbee/ make otr-related messages that pertain to a specific user appear as NOTICEs from that user, causing them to appear distinctly and in the correct window.

NB: besides adding the new function irc_usernotice, rev. 816 refactors irc_usermsg which is now called irc_rootmsg and lets irc_usermsg be the variant parameterized by the user to send as.

please pull.

a problem with NOTICEs is that [at least in irssi] they aren't logged while away and don't trigger a hilight of the window.

this is probably ok for housekeeping messages. to avoid missing the common "not encrypted:" messages while away, tell your irc client specifically to hilight them. e.g. irssi:

/SET hilight_level PUBLIC DCCMSGS NOTICES
/HILIGHT -level NOTICES -regexp The following message received from .* was not encrypted:

[wilmer]

Fixed/Merged.