[OTR-dev] Handling of CTCPs and /me in IRC clients

[Matthew M. Boedicker]

Thanks for identifying this issue Florian. I'll gladly accept patches to
fix this in weechat-otr and I'm going to look at it myself as well.

It does seem like there are some potential security issues so maybe the
default should continue to be encrypt everything unless the user opts-in.


On Mon, Dec 17, 2012 at 8:43 AM, Florian Bruhin <me at the-compiler.org> wrote:

> Heya,
>
> I apologize if someone in the CC is already on this mailinglist.
>
> There are currently some plugins for IRC clients to use OTR, the
> official one for pidgin[0], one for weechat[1], and one for
> irssi/xchat/weechat[2].
>
> Potentially this could also affect Adium[3], CenterIM[4], Kopete[5]
> and Miranda[6], which all speak IRC, but I did not test them. If
> someone could take the time to test this and submit a bug report if
> it's also broken, I'd be glad.
>
> Today I encountered a problem when using OTR: IRC CTCPs[7] seem to be
> broken in all the clients I tested (weechat/irssi/pidgin). This means
> outgoing CTCPs are sent encrypted (because they are just PRIVMSGs as
> well), but ingoing encrypted CTCPs are not handled correctly (i.e. you
> get a literal \001VERSION\001 as a message, for example).
>
> Furthermore I encountered a problem when using weechat with the
> weechat-otr plugin with bitlbee[8] (IRC to IM gateway) and the
> bitlbee_typing_notice[9] plugin: The plugin signalizes to bitlbee the
> user is currently typing by sending a CTCP TYPING, which is parsed by
> the bitlbee server and sent in the respective way to the messenger
> protocol. Now since the CTCP is OTR-encrypted, the server can't handle
> it and it gets passed to the other client, the result is this:
>
> http://the-compiler.org/tmp/bitlbee_otr_ctcp.png
>
> IMHO, this is how CTCPs should be handled:
>
>  - When sending a CTCP TYPING, pass it unencrypted since it's probably
>    directed to bitlbee and won't arrive at the other end. (At least
>    this applies to irssi and weechat, since they both have scripts to
>    do the CTCP TYPING messages, I doubt anyone would want to send them
>    by hand)
>
>  - For any other CTCP, send it encrypted like it is now (it could be a
>    CTCP ACTION aka. "/me" after all)
>
>  - When recieving a messsage which is a CTCP (any part enclosed in
>    \001 inside a PRIVMSG or NOTICE according to [10]) there should -
>    if possible in the plugin APIs - a "fake" CTCP be sent to the
>    client. For "/me" maybe some special action is neccessary.
>
> For weechat-otr, I'll probably send a pull request somewhere after
> christmas. For the others, would be nice if this could be fixed, as at
> least /me and CTCP VERSION are used from time to time.
>
> Florian
>
> [0] http://www.cypherpunks.ca/otr/
> [1] https://github.com/mmb/weechat-otr
> [2] http://irssi-otr.tuxfamily.org/
> [3] http://adium.im/ (OTR builtin)
> [4] http://www.centerim.org/ (OTR builtin)
> [5] http://kopete.kde.org (OTR builtin)
> [6] http://code.google.com/p/mirotr/
> [7] http://en.wikipedia.org/wiki/Client-to-client_protocol
> [8] http://www.bitlbee.org/
> [9]
> http://www.weechat.org/scripts/source/stable/bitlbee_typing_notice.py.html/
> [10] http://www.irchelp.org/irchelp/rfc/ctcpspec.html
>
> --
> () ascii ribbon campaign - stop html mail    www.asciiribbon.org
> /\ www.the-compiler.org  | I love long mails http://email.is-not-s.ms/
> A fool and his honey are soon parted.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20121218/c66a2afd/attachment.html>