[OTR-dev] Re: Verification of OTR plugin for Trillian Pro

[Twan Fox]

Greetings,

Talking a little with Ian and knowing how quite a few are security 
conscience in this particular venue, I had imagined (and in a way, 
anticipated) that this kind of a discussion would come up at some point. 
In particular, this is kind of a strange ground for me to be in because 
I find myself wanting to be able and assured that the work I've been 
doing isn't pilfered if someone feels that I'm not doing what they want 
me to do. I also understand that with the source unavailable as it is 
there isn't much of a way for anyone to do a check on it. While I'm sure 
that this explanation can only be taken at face value, let me elaborate 
a bit on how I built the OTR plugin for Trillian.

Sad to say, this is my first application 'from scratch' that makes use 
of Windows GUI elements as well as interacting with another application 
as a plugin. Because of the difficulties I was going to have with those 
aspects alone, not to mention deciphering how to use the OTR library, I 
turned to the Gaim OTR plugin as a reference guide. Unfortunately for me 
the Trillian API doesn't allow me to do things quite the same as the 
Gaim OTR handled them. Despite that, much of the calls and hooks that 
Gaim OTR made to the OTR library are done so in near identical a way 
between the two plugins, including aspects that I don't fully comprehend.

The goal of the Trillian OTR plugin is primarily to intercept messages 
received by the client and before the medium plugin the message is 
destined for fully processes it and decrypt them (as needed) and 
intercept messages being sent out by the local user and encrypt them (as 
needed) before sending them. At only one time does the Trillian OTR 
plugin attempt to send a message itself (through Trillian and not the 
medium plugin) and that is when the user has configured it to send an 
opportunistic encryption whitespace tag trailing a message. All other 
messages are converted inline (by overwriting an encrypted message 
string with the decrypted message before display, by editing the text in 
the text entry field with the encrypted text before Trillian passes it 
to the medium plugin for processing). What it does not yet do (something 
I'm not sure if the 'risk' is worth investigating in code) is to change 
any settings within Trillian concerning when it logs messages. This 
means that, if the user wants it to, Trillian will log messages that 
have passed through an OTR session. Trillian just doesn't know any 
different.

In the interest of peer review, I have considered the possibility of 
having a member of the OTR development team review the plugin's code, as 
kludgey as it is, in order to give an 'okie dokie' that it doesn't do 
something nefarious. Beyond that, and my conflicted little conundrum, 
I'm not sure quite what would satisfy all involved parties.

Thanks,
Twanfox

Aldert J.B.P. Hazenberg wrote:
> Hi Guys and Girls,
>
> I noticed that Trillian Pro now has an OTR plugin as well !
> (this time Twan of is the cool guy :) found emails from him in otr-dev)
>
> http://www.ceruleanstudios.com/downloads/detail.php?item=378
>
> Again question I have about this :
>
> 1. As it seems to me that this plugin is written by somebody not in
>    the "core" OTR team, should the code not be checked for "issues" ?
>
>    I cannot find the source code of the plugin, something that makes
>    it even harder to check I guess :)
>
> 2. Even if the code is ok, how can i be sure that the ddl supplied is
>    built from that code ? (as the dll is not supplied by the OTR team)
>
> Aldert.
>
>
>
>