Greetings,

Announcing an updated version of the Trillian OTR plugin (v0.5.0 Build 160). This version corrects several crash bugs as well as further enhances functionality that was shown in the UI but not finished in the back-end code. While still a development release, this version should be more stable and more functional than the previous versions.

Description:
Trillian Off-the-Record is a cross-platform encryption plugin. Unlike SecureIM, this style of encryption allows both authentication that the source of the messages is a known individual as well as plausable deniability. Messages sent during an encrypted session are secure, but messages can easily be forged after the fact, preventing them from being easily attributable to any one person. For additional information about the Off-the-Record library used, please visit the OTR Homepage.

Version:
v0.5.0 (Build 160) (Development)

Fixes include:
- Corrected problems with Trillian OTR blocking / commands. (An outstanding issue may involve the /me command. Further work is needed to be done on this specific instance).
- Added enhanced update check functionality
- Corrected one known crash bug when unloading the plugin while windows were open.
- Added Sametime as a medium Trillian OTR will operate on.

Below is a zip containing the plugin, a changelog, and a list of known bugs. If you stumble across anything not listed, please let me know (email address enclosed in the text file).

Plugin Homepage: http://trillianotr.kittyfox.net/

Trillian OTR v0.5.0 (Build 160)

Attached Files

trillian otr 0.5.0-dev build 160.zip (235.0 KB, 54 views)

Updated posted version.

So I finally tested it!

It's fabulous! It's sexy!
No, really, I like the way it's designed, it's really smooth. One can feel that everything which is not smooth is it due to Trillian's limited API. Just about one thing, to distinguish better what the chat partner actually says and what are OTR system message, could you prepend the system messages with *** (OTR) or something like that?

Oh, and, there's some hassle with my test partner's plugin dialog. All preferences pages are blank (see attachment). Any ideas?

[edit]The logo in the Preferences says Trillain instead of Trillian [/edit]

Attached Images

dummsasas.jpg (6.5 KB, 710 views)

(On prepending system messages) I can work on this. I've seen some weirdness in how changing the 'display name' of the message once convinces Trillian that you really want to change it perminently, and that is obviously not something that I want to do. However, since I'm having issues with echoing the proper name to begin with (a task I'm still working on), I can see whether or not there's a way to convince it to play nicely with the display name just once. I'm also looking to see how I can log messages to the console window of that connection. As a medium plugin, that seems easy. As a translation-type plugin, that may not be so easy.

(On the 'logo' typo) Oops. *looks sheepish* That aught to teach me to proofread my logo before I incorporate it into the plugin. I'll get that fixed and include it in the next round. Consiquentally, if you know anywhere to get more viable icons for use in an app such as this, I'd be indebted. My artsy creative side isn't as swift as my programming side.

(On the preferences dialog) I can look into it, though in both my regular accounts and my testing accounts, the preferences dialog comes up okie dokie. The UI is based off the standard Win32 API (with the Windows Template Library assisting out to make it easier in code). What version client? What other plugins are in use on his client? How did the preferences get opened (one way is the standard 'Change' button. The other way is through a message window menu)? Can take this to PM if you like, save on board spam.

[edit] It looks like, for some reason or another, the plugin wasn't properly initialized. As you see from the image, the pref dialog lists the entries, but the 'title' and 'description' of the plugin preferences is default. I'll see how this could possibly happen in code.[/edit]

And thanks for the compliment. There's still more to do and some API calls to decypher. A consiquence of them not being well documented, I suppose, but it'll get done And hopefully, if a new version of Trillian is on the way, the API will be much improved for such tasks as these.

Yes!

I love it.

We have been waiting for this for so long.

Kudos. Very great. Thank you.

In the spirit of improving this very important and very fine plug-in, here are two small things:

1. when I hit the "check for update" button, there is no feedback

2. attached is a screengrab showing the OTR key generator showing the name if the account just below the account I am on, as the name it is generating the key for at that momment. Not really all that important, I just did a key for each of my accounts, knowing that it just had the name off by one.

Keep up the great work.

Oh, one last small question, in GAIM, there is that button in the bottom left of the chat window to begin or refresh an OTR converstaion. Is there such an animal here?

Peace. Love.

xmpp:jason@sjobeck.com

Attached Images

otr-offset-msg.jpg (64.2 KB, 652 views)

Thank you thank you thank you thank you thank you thank you!

Sjobeck,

The 'Check for Update' was not ready yet, and unfortunately, the disabled flag I threw on that control didn't quite disable it obviously. The infrastructure and backend code for the button is now in place for those update checks to be done. I'm still settling on a proper 'version' schema to use so that 'update needed' statements make sense.

Understood on the 'off by one' error on the key generation dialog. I had noticed that myself, but as a stupid little crash bug on my debug sessions was drawing my attention more. It looks like it isn't quite an off by one, but mismatched entries between an internal structure and the visible dropdown box. I located a better method to associate the dropdown entry and the data element together, resolving that issue.

As for the 'button' on the message windows, yes, this can be done. Unfortunately, as that requires a bunch of skinning support/searching and effort to locate needed elements and controls, I have not yet reached the point where I can go after that as a way to make the connection state plainly obvious. A menu bar entry should be present currently in message windows (under the heading 'Trillian OTR') to control that particular conversation's state. This seemed best at the time since adding it to the right click menu apparently destroys any other right click menu that was in existance.

Thanks for the vote of confidence. Now if I can just isolate that nasty little crash bug, I'll be happy.

Twan

Yes

Yes.

Understood.

Understood.

Agreed.

Agreed.

Thanks.

Thanks.

Go baby go.

Go baby go.

I would like to mention a few other minor things, just to lend a hand to the developer:

1. If a key for an account has not been generated yet, and there is a chat going on for that account, and the user chooses "start conversation" from under the "Trillian OTR" menu in the chat window, there is no output. The conversation continues unencrypted. There is no note to the (ignorant) user that they do not have a key for that account. Maybe the (ignorant) user could be advised to go generate a key before trying an OTR conversation.

2. It is wild to watch my CPU spike & peg itself for 60 seconds while my key is generated. The (ignorant) user might not understand why this is, and perhaps somehting in the doc's might advise him that this operation is extremely intensive & momentary & one-time only.

Like I say, minor.

Thank you.

"twanfox"

You know what, after a day's use of this excellent plug-in, you know what, there is no need for a button similar to GAIM's button in the lower left for conversation state and or refr4esh, the menu item is perfect. Stick with that. I have come to like it a lot. Plus, it gives the user more real estate on the screen for what they really care about any way.

Scratch my earlier note about that button. What you have is spot on.

Thanks again.

It is possible to add to the right click menu with-out destroying the original menu. If you are still interested in doing so, I'd be willing to help you find your problem.

"skiingwiz"

But dont you dig on the menu item though? I sure do.

The more I used it, the more I realized it is "the right place"(tm) to put those controls.

$0.04 worth.

Peace.

I would most certainly be willing to include those items on the right click menu as well. I would not abandon the menu bar option (as it is a plainly visible menu), but if you notice, most of the features of a medium, such as sending a file, are available in 3 places in a message window. The 'Actions' menu bar, the Toolbar as a visible icon, and the right click menu. Inclusion in the right click menu would allow people (like me) who prefer the context menus to use those and others to use the other methods.

Additionally, addition of a Toolbar button would allow for a visible status on the current encryption state. That is one thing that the system lacks right now, since the 'MessageSetState' doesn't seem to actually work to toggle on or off the 'SecureIM' lock icon in the message window.

Sjobeck,

There is an obvious need for additional messages posted to the windows during ending a conversation, as well as streamlining the autogeneration of a new key on an incoming session. I had missed the lack of response when a new session was attempted to be initiated without a key, and I can go one step further by having the code fire off that keygen before attempting initiation of the session. A good improvement to include.

Posted updated version. This should (hopefully) reduce the known crash bugs to 0, though other bugs do still exist.

Twanfox - where are you hosting the plug-in?

It's an attachment to this thread, second message from the top. It'd BE in the top message if it would allow me to add a new attachment there.

Oh ok.. I just read the latest post saying it had been updated, and so I wondered where to go get the *new* one. The one at the top of the thread is the one I got yesterday -- unless you updated THAT one, in which case I don't have the latest one ;-)

Thanks again for the plug-in... I see that you've already thought of the only thing I'd really ever ask for (visual cue to let you know you're encrypted). I'm a happy camper chatting away with my friends on GAIM now -- telling them how much better I've got life on Trillian ;-)

Tim

Very cool plug-in, thanks for developing it. I'll have to get a few friends to try out its functionality

All,

FYI:

http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.html

Pretty strong stuff!

Peace.

xmpp:jason@sjobeck.com

Sweet plugin. I also have the blank dialog problems. Perhaps there is an unfufilled DLL requirement? Just grasping at straws here. I know I've seen GDI elements not draw because of it before.

Please list the following information: Operating system version and service pack. Trillian Version. Which version is listed in the 'Trillian OTR' dialog (Should be build 145, but I have to ask).

I can test most versions, but I need as much information as I can get to replicate the problem. Between build 101 and build 145, I noticed I was passing a null hwnd to the dialogAdd API call and corrected it, but on Windows XP SP2, in Trillian version 3.1, the dialog box displayed regardless of that bug.

Thanks,
Twan

Hi there, I found a minor issue with the plugin, I'm not sure if anyone has mentioned it or if it's well known or not.

By enabling the plugin, I wasn't able to input Trillian commands in the message window (such as "/clear" to clear the message texts, and probably other commands also).. Has anyone else noticed the same thing?

Windows XP SP2
Trillian 3.1 build 121
Plugin calls itself 0.5.0-Dev. Name of ZIP is build 145.

Thanks for the quick response!

notchO,

I was not familiar with that behavior of Trillian, to allow you to clear the screen. It may have something to do with the hooks I use to nab the data that Trillian is using to send messages back and forth.

Basically, I use the message_broadcast event handler and the 'edit_sendText' edit event to pull both incoming and outgoing data that passes through Trillian's messaging system. It seems likely that the 'edit_sendText' event with the opportunistic OTR setting is the cause of the problem, though it may extend to any other edit_sendText event handler that attempts to interpret data before Trillian sends it out.

If you can lay out a set of enabled plugins, the sequence of events, version numbers, and any related information that might influence Trillian's behavior to me, I might be able to reproduce the error and track it down through a debugger. Additionally, crash logs are also of use, should any be produced.

Thanks,
Twan

Hi Twan,

I have only the standard Trillian plugins enabled:
AIM/Icq
MSN
Yahoo
Trillian OTR

Running Trillian Pro 121

If you open a message window to a contact, in the message input area, type in "/clear", normally it would clear the entire message display area above the input area; however, if I enabled OTR, when key in "/clear", the text is sent to the contact instead.

Thanks,
notchO

Huh. Are there a known list of commands like that? I mean, I can cause the OTR plugin to fail to change anything should the input text match exactally one of those commands, but I'd need to know what the commands were to do that.

it seems that the <cursor/> wasnt' the only buggy tag, <su> seems to stick too.
<su> is used by the spellchecker plugin to indicate squiggly underlines, but shouldn't be sent witht he message, as other clients don't appera to support it
it doesn't appear to be specific to the spellchecker's usage of it either, even adding it myself with raw edit in a different color still stays

also, any aliases registered with trilly by other plugins, such as /botignore and /botrespond with est's trillalice plugin don't work in OTR chats. perhaps an option to not OTR any messages starting with a '/' ?

/me goes off to look for more bugs....

[EDIT]oh yeah, almost forgot, the handy ctrl-up message recall seems to be rendered useless by OTR, it simply recalls something looking like this:

The <su> tag is also used by the instant lookup feature, so I assume that will also cause the problem.

Is the <su> tag only ever inserted once into the string, like the <cursor/> obviously would seem, or is it possible to have it in multiple places? Is there an opening/closing tag, or is it just the <su> tag? A sample message post-send showing the offending tags would help me to know how I have to search and remove them from the text.