Fixing (Encryption + AIM Direct IM)

Wed Dec 17 15:10:20 EST 2008

And Evan Schoenberg spake on 12/17/2008 08:21 AM, saying:
> Currently, oscar.c's purple_odc_send_im() gets called after all 
> plugins have a chance to act via the "sending-im-msg" signal. 
>  purple_odc_send_im() then does the parsing on the message to change 
> any IMG tags (associated with purple imgstore objects) into the 
> appropriate tag and binary data to send images over the wire.  
>
> On the other side, peer_odc_handle_payload() parses the received 
> message to do the reverse conversion: binary data to purple imgstore 
> objects and their tag references.
>
> That's all well and good except that it fails miserably if the message 
> being sent is encrypted, as with the OTR plugin, 
> because purple_odc_send_im() and peer_odc_handle_payload() both see 
> encrypted data and have no way of doing their thing.
>
> I'd like to fix this.  One thought I had was to add a prpl callback 
> which can be queried to see if the prpl will handle posting 
> sending-im-msg and receiving-im-msg itself.  If it returns true, then 
> the normal signals won't be posted by server.c/conversation.c.  Oscar 
> prpl would return true only if the chat is a direct im chat... and 
> then would post those signals from the appropriate _odc_ methods at 
> the appropriate time.  Does that sound reasonable?  Anyone have a 
> better solution?
>
> Cheers,
> Evan

I love the idea -- it could also make OTR behave a little better in the 
XMPP world, where it currently sends Purple IM markup encoded in the 
<body> element (ideally it would encrypt the plaintext-formatted and 
XHTML-IM markup separately and stuff the marked-up content into the the 
XHTML tag.)

I think this has the serious potential to break OTR and cause a loop, 
though. If a message is 'too big' (by OTR's definition), it will 
fragment the message and reinject multiple ones (via serv_send_im). It 
should be possible to have prpls wrap calling the sending-im-msg signal 
in a check that it's not currently in that signal handler, but that 
would require all prpls that handle the signal to do that (and I can see 
bad situations with 3rd-party prpls not offering that protection).

~Paul