[OTR-dev] OTR + Second Life Client

[Ian Goldberg]

On Sun, Jul 19, 2009 at 12:27:52AM -0700, chris-tuchs at hushmail.com wrote:
> I have gotten OTR compiled

Using a native Win32 compiler like VC++?  We'd love it if you posted
some detailed instructions on how to get that to work!

> and working in the Greenlife Emerald Viewer for Second Life.

Fantastic!

> I have
> not yet implemented any way to 
> authenticate a buddy; that is what I will be working on next.  
> However I wanted to put out an early plea for experienced OTR devs 
> to audit the code.  If you are interested in ensuring I didn't do 
> something dumb that might make OTR look bad, please send me an 
> email and I'll arrange for you to see the code.

While I good idea in theory, that would pretty much have to be me
personally, and I don't have the cycles to audit all third-party code
that uses OTR, unfortunately.  :-(  Normally we suggest ensuring that it
interoperates with other OTR-enabled software, but in your particular
case, I can imagine that might be tricky, since you're not talking to an
IM network that other OTR clients can speak to.

> One sign I may be doing something dumb is that during the compile 
> of OTR there are a number of warnings in the cryptographic 
> libraries.  Although most look OK to me, a few look serious.  I am 
> most concerned about those in libotr's auth.c and in libgcrypt's 
> mpih-div.c.  Thanks for your time!

Comments below.  Upshot: don't worry about it.

> 24>------ Rebuild All started: Project: libotr, Configuration: 
> RelWithDebInfo Win32 ------
> 24>Deleting intermediate and output files for project 'libotr', 
> configuration 'RelWithDebInfo|Win32'
> 24>Compiling...
> 24>auth.c
> 24>..\..\libotr\libotr-3.2.0\src\auth.c(385) : warning C4333: '>>' 
> : right shift by too large amount, data loss
> 24>..\..\libotr\libotr-3.2.0\src\auth.c(416) : warning C4333: '>>' 
> : right shift by too large amount, data loss
> 24>..\..\libotr\libotr-3.2.0\src\auth.c(523) : warning C4333: '>>' 
> : right shift by too large amount, data loss

Are the three lines above all of the form (pubkey_type >> 16)?  That was
a bug that's since been fixed in CVS; it should be 8, not 16.  But it
doesn't affect anything right now, since the only existing pubkey_type
is 0.

> 24>sm.c
> 24>..\..\libotr\libotr-3.2.0\src\sm.c(358) : warning C4018: '<' : 
> signed/unsigned mismatch
> 24>..\..\libotr\libotr-3.2.0\src\sm.c(362) : warning C4018: '<' : 
> signed/unsigned mismatch
> 24>..\..\libotr\libotr-3.2.0\src\sm.c(363) : warning C4018: '<' : 
> signed/unsigned mismatch
> 24>..\..\libotr\libotr-3.2.0\src\sm.c(370) : warning C4018: '<' : 
> signed/unsigned mismatch

No big deal, but it could be cleaned up.

> 24>proto.c
> 24>..\..\libotr\libotr-3.2.0\src\proto.c(785) : warning C4018: '>' 
> : signed/unsigned mismatch

Also not a big deal, since a signed int is being compared to an unsigned
short.

> 24>privkey.c
> 24>..\..\libotr\libotr-3.2.0\src\privkey.c(243) : warning C4018: 
> '<' : signed/unsigned mismatch
> 24>libotr - 0 error(s), 9 warning(s)

No issue here.

I can't comment on the libgcrypt issues.

   - Ian