Fixing (Encryption + AIM Direct IM)

Thu Dec 18 11:51:59 EST 2008

On Dec 17, 2008, at 3:10 PM, Paul Aurich wrote:

> 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).

Also: What happens if the plaintext and the XHTML-IM messages require  
different number of fragments?

I thought about fragmentation in the AIM Direct IM case.... but it's a  
nonissue because over Direct IM there is no maximum packet size, so  
fragmentation simply never occurs.  XMPP does have a maximum message  
size, though?

-Evan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20081218/1611803b/attachment.sig>