On Tue, Sep 10, 2013 at 10:25:54PM +0200, Thijs Alkemade wrote: > > On 10 sep. 2013, at 20:02, Jurre van Bergen <[email protected]> wrote: > > > > > Signed PGP part > > On 09/10/2013 07:46 PM, Jacob Appelbaum wrote: > > > Heya, > > > > > > There exists an information leak in Pidgin/Pidgin-OTR where Pidgin > > > doesn't allow Pidgin-OTR to encrypt a specific message before it is sent > > > to the network. Specifically on IRC networks, users who emote through > > > the use of a message such as `/me thinks this is a bug` - will leak the > > > full text of their /me command. > > > > > > This is annoying and it would be nice if Pidgin didn't treat /me > > > messages in this way. It appears that around the same time as learning > > > about this bug, I found a bug report with a fix for Pidgin itself. > > > > > > If there are any Pidgin/Pidgin-OTR users on this list who also use IRC > > > with Pidgin, it would be great to see if the following patch fixes the > > > behavior of /me on irc: > > > > > > https://developer.pidgin.im/ticket/15750 > > > > > > This could also be fixed inside of Pidgin-otr - though I think the right > > > place is inside of Pidgin itself. It would be useful if IRC using > > > Pidgin-OTR developers could test the patch attached to ticket 15750 on > > > the Pidgin bug tracker. > > > > > > Useful questions to answer: > > > > > > Does it solve the /me info leak for you? Does it cause any adverse > > > issues? Does it make sense to put this into Pidgin-OTR? > > > > > > All the best, > > > Jake > > > > > > > I tested this patch a few weeks ago and it doesn't fix the current issue > > in IRC while being in an OTR conversation. > > > > Jurre > > Hello, > > I'm the author of that patch. One thing to note about it is that it doesn't > fix the decryption: If you send "/me nods." from Pidgin to Pidgin, the > receiver will see it as "\001ACTION nods.\001" (or whatever weird characters > GTK uses to render \001). > > The possible solutions for that would be: > > - Pidgin-OTR passes a decrypted message to back irc_parse_ctcp() to be handled > like normal CTCPs. That would be a bit of a hack, as I don't think Pidgin-OTR > currently needs to differentiate between different protocols like that and > this would create a hard dependency between Pidgin-OTR and the IRC prpl. > > - Pidgin-OTR replaces all occurances of "\001ACTION foo.\001" with "/me foo." > when decrypting. This is not a pretty solution either, but at least it would > not create a dependency of Pidgin-OTR on the IRC prpl. > > - Pidgin-OTR uses different libpurple signals. For example by hooking "irc- > receiving-text" and "irc-sending-text" it would be possible to encrypt every > CTCP (including ACTION) and decrypt them while maintaining the handling for > them by libpurple. Downside of this is that Pidgin-OTR needs to be able to > parse and generate IRC PRIVMSGs. > > The last one would also make this patch unnecessary. > > I have not been able to reproduce the problem Jurre had with my patch. Using > Pidgin on Wheezy with my patch I've verified with Wireshark that everything > is encrypted when sending "/me". > > Regards, > Thijs
(Warning: it's been probably more than a decade since I looked at the irc low-level protocol.) If the user types "/me nods", what do you *want* to get sent over the wire? \001ACTION ?OTR:AAMD... (which leaks that it *was* an action, and its approximate length) \001PRIVMSG ?OTR:AAMD... where the plaintext starts with "/me "? In any event, isn't it the case that the prpl-irc plugin can modify the plaintext of the action however it likes, raise sending-im-msg, and then massage the result however it likes? (Some care will need to be taken to deal with fragmentation.) - Ian _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
