From: Ludovic L. <ll...@us...> - 2003-07-25 01:24:27
|
Hello list, I've just uploaded ( http://sourceforge.net/tracker/index.php?func=detail&aid=777300&group_id=235&atid=300235 ) a patch to add preliminary support for encrypted communication, compatible with Trillian SecureIM protocol. It is just a proof-of-concept. Here is the summary : ====================================================== That patch adds preliminary support for receiving Trillian's SecureIM messages (encrypted IM) over Oscar protocol. It may (or may not) work for you. Please report to the list. Current limitations : * Receive only. You'll be able to read (decrypt) encrypted messages, but you cannot send messages in encrypted form. * No UI. Always on. * Full of bugs, and assumptions about SecureIM protocol. * Seems only to work with AIM. Should work with ICQ but currently don't. * I don't know a thing about encryption. * I don't know a thing about GAIM's internals so the implementation may be a complete heresy. (and that's why I didn't add support for sending messages, I couldn't understand it enough) * You need OpenSSL compiled and installed as a library. I used version 0.9.7b ( http://www.openssl.org/source/ ) * Was developped on a Windows workstation, so the Makefiles aren't correctly updated (only Makefile.mingw). You'll have to tweak to link with OpenSSL. I don't know how. * Totally unsupported. I may never work on this again. Known Bugs : * ICQ doesn't work for me : the server doesn't transmit our ACCEPT packet to the other party. Don't know why. Either a problem with my account, or an initialisation problem. ====================================================== 4 more points : * You will need OpenSSL as noted, I don't know if there is a problem with OpenSSL license ( http://www.openssl.org/support/faq.html#LEGAL2 ) but don't really care about. * Many thanks to the Joust project ( they publish JOscar, a Java OSCAR library ) for the documentation and all the trial-and-errors work for guessing the protocol. You can find JOscar here ( http://joust.kano.net/joscar/ ), the classes that concern Trillian protocol are in 'net.kano.joscar.rvcmd.trillcrypt', there you will find some documentation. They seem very close to a working implementation. * I don't know about Cerrulean Studio's reaction. I wish to thank them for chosing a public key exchange mechanism and a public cipher, and giving hints about them on their web site. (If there were any doubts about it, I didn't reverse engineer their code nor anything like that.) Moreover they chose very standard (and easily guessable) parameters, which is a plus for interoperability. * (for those, like me, who don't really know about encryption : ) Being able to interoperate with Trillian doesn't mean that their protocol is 'weak'. It only means that they chose a public cipher, and that using the same one leads to the same results, which is a good thing. As noted, this work is totally unsupported. I wanted badly to be able to make GAIM interoperate with Trillian, so I tried my best and with great luck it seems to work. However, I'm not sure I'll improve this and maintain it as a separate patch. My best hope is that it gets included in the CVS and that an 'autoconf' master adds the '--with-trillian-secureim' option that I couldn't add. Then, people will have to add an UI to enable / disable encryption, support for sending IM (that would be so cool !), etc... Best regards, Ludovic LANGE. |
From: Christian H. <ch...@gn...> - 2003-07-25 02:22:51
|
On Fri, Jul 25, 2003 at 03:23:25AM +0200, Ludovic LANGE wrote: > * You will need OpenSSL as noted, I don't know if there is a problem=20 > with OpenSSL license ( http://www.openssl.org/support/faq.html#LEGAL2 )= =20 > but don't really care about. We care very much about it. It is indeed a problem, and a violation of our license. You'll have to find another method for doing this, such as Mozilla's NSS. See the earlier thread from this month or last regarding gaim-encryption. Christian --=20 Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ Civilization, as we know it, will end sometime this evening. See SYSNOTE tomorrow for more information. |
From: Ludovic L. <ll...@us...> - 2003-07-25 11:43:29
|
Christian Hammond wrote: > On Fri, Jul 25, 2003 at 03:23:25AM +0200, Ludovic LANGE wrote: > >>* You will need OpenSSL as noted, I don't know if there is a problem >>with OpenSSL license ( http://www.openssl.org/support/faq.html#LEGAL2 ) >>but don't really care about. > > > We care very much about it. It is indeed a problem, and a violation of > our license. You'll have to find another method for doing this, such > as Mozilla's NSS. See the earlier thread from this month or last > regarding gaim-encryption. > > Christian > Sorry Christian, no offense intended. I just meant that as it was a proof-of-concept on my computer (where OpenSSL is already installed) it wasn't very important for me. Of course, now that I have made the code public the problem does exist, and I'm sure there are people that understand far better than me all this discussions about licenses (in fact I *have* been fooled by OpenSSL FAQ which said it was possible.) I'll try to have a look at Mozilla's NSS to see if it fits my purposes : being cross-platform compatible (in particular, able to build on Windows without me messing with the makefiles that I know nothing of) and having support for both diffie-hellman and bluefish. Best regards, Ludovic LANGE. |
From: Robert M. <rob...@de...> - 2003-07-25 12:34:48
|
On Fri, Jul 25, 2003 at 01:42:43PM +0200, Ludovic LANGE wrote: > Sorry Christian, no offense intended. I just meant that as it was a > proof-of-concept on my computer (where OpenSSL is already installed) it > wasn't very important for me. It's not a particularly good idea to contact the authors of software and say you don't care about their license. We care very much about keeping Gaim free (in all senses of the word) and complying with the GPL, and that includes not linking with OpenSSL, and not distributing binaries which do so. > Of course, now that I have made the code public the problem does exist, > and I'm sure there are people that understand far better than me all > this discussions about licenses (in fact I *have* been fooled by OpenSSL > FAQ which said it was possible.) Actually, I don't think writing the code or making it public is a problem. I think the problem only arises when you compile the code and load it into Gaim, or distributing compiled binaries. > I'll try to have a look at Mozilla's NSS to see if it fits my purposes : > being cross-platform compatible (in particular, able to build on Windows > without me messing with the makefiles that I know nothing of) and having > support for both diffie-hellman and bluefish. Ermm, the cross-platform nature of NSS is what makes us prefer it to the other non-OpenSSL library, GNUTLS. NSS is available on every platform that Mozilla is, and that covers most unixes, Windows and Mac. It should have fairly good support for a variety of cryptographic methods. It will definitely have diffie-hellman, it's *the* key exchange protocol. And did you mean blowfish? It will have that. > Best regards, > > Ludovic LANGE. Regards, Rob |
From: Ludovic L. <ll...@us...> - 2003-07-27 23:11:45
|
> It's not a particularly good idea to contact the authors of software and > say you don't care about their license. We care very much about keeping > Gaim free (in all senses of the word) and complying with the GPL, and > that includes not linking with OpenSSL, and not distributing binaries > which do so. I fully agree with your point of view. My first message wasn't well thought, and I apologize if it's wording did offense someone. So let me say it again : I am now informed, and do care about the GAIM / OpenSSL license incompatibility, and although I deplore this first choice of mine, I will do my best to adapt the patch and use NSS as an alternative to comply with the license problem, so that people can test the code. > Actually, I don't think writing the code or making it public is a > problem. I think the problem only arises when you compile the code and > load it into Gaim, or distributing compiled binaries. Understood. However the fact of releasing the code developped for OpenSSL will lead to this problem. I don't think (haven't digged into it yet) that NSS is API-compatible with OpenSSL. > Ermm, the cross-platform nature of NSS is what makes us prefer it to the > other non-OpenSSL library, GNUTLS. NSS is available on every platform > that Mozilla is, and that covers most unixes, Windows and Mac. It should > have fairly good support for a variety of cryptographic methods. It will > definitely have diffie-hellman, it's *the* key exchange protocol. And did > you mean blowfish? It will have that. Good. I'm downloading it right now. ... After a quick check, I don't think I've seen support for blowfish. Does anybody know if it is supported ? I'll keep the list informed. Regards, Ludovic LANGE |
From: Ludovic L. <ll...@us...> - 2003-08-29 17:39:38
|
Hello, A new version of my patch to add (read-only) support for Trillian 'SecureIM' encrypted message, is available on SourceForge ( http://sourceforge.net/tracker/index.php?func=detail&aid=777300&group_id=235&atid=300235 ). It can now be compiled with 'libgcrypt' ( http://www.gnu.org/directory/libs/libgcrypt.html ) instead of previously OpenSSL. Libgcrypt is a GNU package, licensed under LGPL, so there shouldn't be any license incompatibility any more. I could'nt use NSS (that has beeen suggested on the list) because it doesn't support the blowfish encryption algorithm that is needed. On the contrary, libgcrypt allows this ciper to be used, and allows a straightforward implementation of the diffie hellman key exchange. To use this patch you'll need : * libgcrypt 1.1.42 installed and working, * applying the patch to a recent CVS snapshot * modifying src/protocols/oscar/Makefile to add -lgcrypt somewhere, modifying LIB_PATH and INCLUDE_PATH (have a look, in the patch, to Makefile.mingw), and adding 'trillcrypt.c' in the OBJS. * recompile liboscar. This patch was only tested in a Win2000 (MinGW32 3.0.0-rc4 + GCC 3.3.1) environment. YMMV. Best regards, PS: Luke, could you please re-open the tracker item ? Thank you. Ludovic LANGE |
From: Robert M. <rob...@de...> - 2003-08-29 18:04:03
|
On Fri, 2003-08-29 at 17:25, Ludovic LANGE wrote: > Libgcrypt is a GNU package, licensed under LGPL, so there shouldn't be > any license incompatibility any more. Good to hear. > I could'nt use NSS (that has beeen suggested on the list) because it > doesn't support the blowfish encryption algorithm that is needed. On the > contrary, libgcrypt allows this ciper to be used, and allows a > straightforward implementation of the diffie hellman key exchange. This is a little unfortunate - it's likely to stop your code being accepted into Gaim (although I'm not sure it'd ever be allowed in, given that AOL now has their own encryption which we will probably be expected to support, and Trillian will do too). If it comes down to it, blowfish is a pretty simple algorithm, so you could just borrow an implementation of it to include in your code. > To use this patch you'll need : > > * libgcrypt 1.1.42 installed and working, > * applying the patch to a recent CVS snapshot > * modifying src/protocols/oscar/Makefile to add -lgcrypt somewhere, > modifying LIB_PATH and INCLUDE_PATH (have a look, in the patch, to > Makefile.mingw), and adding 'trillcrypt.c' in the OBJS. > * recompile liboscar. Is Trillian's SecureIM really for Oscar only? Can this code not be implemented as a plugin to Gaim rather than a patch? > This patch was only tested in a Win2000 (MinGW32 3.0.0-rc4 + GCC 3.3.1) > environment. YMMV. > > Best regards, > > Ludovic LANGE Regards, Rob |
From: Ludovic L. <ll...@us...> - 2003-08-29 20:40:49
|
Hello Robert, Thanks for your answer. >>I could'nt use NSS (that has beeen suggested on the list) because it >>doesn't support the blowfish encryption algorithm that is needed. On the >>contrary, libgcrypt allows this ciper to be used, and allows a >>straightforward implementation of the diffie hellman key exchange. > > > This is a little unfortunate - it's likely to stop your code being > accepted into Gaim (although I'm not sure it'd ever be allowed in, given > that AOL now has their own encryption which we will probably be expected > to support, and Trillian will do too). If it comes down to it, blowfish > is a pretty simple algorithm, so you could just borrow an implementation > of it to include in your code. Can you please detail what is infortunate ? I'm not sure I have fully understood what you meant. If you meant that you'd prefer NSS instead libgcrypt according to your previous arguments (cross-platform nature of NSS vs less platforms supported by libgcrypt), there are a few things that we must consider : * NSS is too big enough. It does so much things that I don't need ( I hardly need 1% of the library), it's hard to setup. The only thing I will need from NSS is the Diffie-Hellman key exchange. Which, if you read my patch, is so simple that only a 'Big Number' library like GMP will be enough. * NSS doesn't support the blowfish Cipher, and I'm not going to write it. The only things I've seen from NSS make me want to stay away from it. Just to be more precise, the patch only needs two things : * a Diffie Hellman key exchange (which I've re-written from scratch using the libgcrypt 'Big Number' library, but could be done with GMP also) * an implementation of the Blowfish cipher. I found that libgcrypt implementation was ok. I'm not going to rewrite the blowfish cipher. Cryptography is not my field of expertise, and I'm not interested. > Is Trillian's SecureIM really for Oscar only? It is. It's based on low-level proprietary (Trillian's) extensions to the Oscar protocol. > Can this code not be > implemented as a plugin to Gaim rather than a patch? No, for the precedent reason. It is *not* the encryption of the message through normal paths, but rather an extension of the Oscar protocol. I'd have written a plugin if it were possible, of course. Regarding AOL's new encryption vs Trillian's : This patch is to be considered as a 'interoperability layer' with current Trillian offering. There are people using Trillian's SecureIM, and this allows to interoperate with these people (well kind of : only receiving message for the moment). When Trillian have updated their free client (v0.74D) to support AOL's new encryption, this patch will be obsolete. However, I saw no sign that thei upcoming version (v 2.0 pro) will be free. So people will keep on using the current 0.74D Best regards, Ludovic LANGE. |
From: Robert M. <rob...@de...> - 2003-08-30 00:05:13
|
On Fri, 2003-08-29 at 21:40, Ludovic LANGE wrote: > Can you please detail what is infortunate ? I'm not sure I have fully > understood what you meant. Gaim's Jabber maintainer has already stated that he's not going use libgcrypt, but instead wants to implement Jabber SSL using NSS (although I think I disagree with this decision, libgcrypt is becoming very common and its portability has been improving recently). It does not make sense to have Gaim linked to two libraries that provide the same feature set. > I'm not going to rewrite the blowfish cipher. Cryptography is not my > field of expertise, and I'm not interested. I meant that you take a copy of it from somewhere else, not write your own implementation. Not that it matters now, for the reasons given (above and particularly below, and in the mail Ethan sent) your patch is unlikely to be merged anyway. > When Trillian have updated their free client (v0.74D) to support AOL's > new encryption, this patch will be obsolete. However, I saw no sign that > thei upcoming version (v 2.0 pro) will be free. So people will keep on > using the current 0.74D I don't think Gaim wants to support a broken crypto implementation for the benefit of interoperating with people who use a broken version of a broken IM client on a broken operating system. They can fix at least a few of those by switching to Gaim for Windows, but the free release of Trillian is horribly broken in so many ways. > Best regards, > > Ludovic LANGE. Regards, Rob |
From: Ludovic L. <ll...@us...> - 2003-08-30 02:10:32
|
Hello Robert, >Gaim's Jabber maintainer has already stated that he's not going use >libgcrypt, but instead wants to implement Jabber SSL using NSS (although >I think I disagree with this decision, libgcrypt is becoming very common >and its portability has been improving recently). It does not make sense >to have Gaim linked to two libraries that provide the same feature set. > > I think you mean GnuTLS. GnuTLS does provide SSL, and needs libgcrypt for low-level. libgcrypt is really a low-level library. No comparison with the huge NSS. >I meant that you take a copy of it from somewhere else, not write your >own implementation. Not that it matters now, for the reasons given >(above and particularly below, and in the mail Ethan sent) your patch is >unlikely to be merged anyway. > > Making a copy is not something I like in general : * It is costly (writing glue, separating what is necessary from what is not, you need to understand both the implementation and the concepts, etc...) * It is wrong maintenance-wise : while the library will evolve, you will have to frequently check the changes in the mainstream, and backport them to your implementation, * It is also wrong because it goes against the concept of libraries : Someone already bothered to make a library, maintain it, package it, document it. I prefer to consider that there are existing components (and perharps choice among different implementations), and that we glue all these components together when we need them. The library maintainer keeps his responsability over his work, because he is competent and experienced, and we don't always want to know the insides of the implementation. We only want a working implementation. It's not *that* bad the patch is not merged. It now exists, and if someone needs it, he is free to apply it. That is what open source is for, choice, isn't it ? >I don't think Gaim wants to support a broken crypto implementation for >the benefit of interoperating with people who use a broken version of a >broken IM client on a broken operating system. They can fix at least a >few of those by switching to Gaim for Windows, but the free release of >Trillian is horribly broken in so many ways. > > I think I disagree with you. I don't really like the Windows plateform more than you seem to do. However, let's face it, today, in the real world, desktop means either Windows or Mac OS. (It may change in the future, I sincerly hope so, but that's what I noticed (btw : I *did* in a previous job have a Linux laptop.) ). Concerning Trillian, I don't agree either. It may be broken (file transfer for instance), but it is enough for basic Instant messenging, and that is what people want. Besides, it offers multiple protocols (MSN / AOL / ICQ are the most used) and for most people it will be better to use Trillian than using ICQ + AOL + MSN (less memory-bloat, etc...) I don't have any figures, but from my personal experience, Trillian IS used, broken or not. Interoperability, I think, is the first step towards migration (from Trillian to WinGaim) for basic users. However, all this is unimportant. I have fullfilled my needs, and have contributed my findings back to the community in case it is of interest to someone. I do understand that there are reasons for this patch not to go in, and perharps this is wiser. My mission is over. Best regards, Ludovic LANGE |
From: Nathan W. <fac...@fa...> - 2003-08-30 07:09:01
|
On Sat, Aug 30, 2003 at 01:05:07AM +0100, Robert McQueen wrote: > On Fri, 2003-08-29 at 21:40, Ludovic LANGE wrote: > > Can you please detail what is infortunate ? I'm not sure I have fully= =20 > > understood what you meant. >=20 > Gaim's Jabber maintainer has already stated that he's not going use > libgcrypt, but instead wants to implement Jabber SSL using NSS (although > I think I disagree with this decision, libgcrypt is becoming very common > and its portability has been improving recently). It does not make sense > to have Gaim linked to two libraries that provide the same feature set. <snip> Rob, please don't put words in my mouth. I want to understand as little SSL as possible to implement it, which means I'll implement it using whatever we link into the core. The current direction we seem to be going in is NSS, so I guess I'll use NSS. If we decide gcrypt is better, I have no issue with that. Nathan --=20 Nathan Walp || fac...@fa... GPG Fingerprint: || http://faceprint.com/ 5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E |
From: Robert M. <rob...@de...> - 2003-08-30 12:11:17
|
On Sat, 2003-08-30 at 07:59, Nathan Walp wrote: > Rob, please don't put words in my mouth. I want to understand as > little SSL as possible to implement it, which means I'll implement it > using whatever we link into the core. The current direction we seem to > be going in is NSS, so I guess I'll use NSS. If we decide gcrypt is > better, I have no issue with that. > > > Nathan Sorry, I thought it was you who was aiming for NSS. I don't think GNUTLS is all that bad, and given OpenSSL's license issues, it's easily becoming the most popular not-OpenSSL implementation of SSL. Not to mention there are plenty of patches around to add SSL support to Jabber with GNUTLS: http://cvs.rutgers.edu/viewcvs/viewcvs.cgi/source-patches/gaim-0.64-tls%2Bru.patch?rev=1.1&content-type=text/vnd.viewcvs-markup Although you can do it with stunnel: http://www.phy.duke.edu/~icon/misc/jabber-howto.html Regards, Rob |
From: Bjoern V. <bj...@cs...> - 2003-08-31 13:32:24
|
On 30.8.2003 Robert McQueen <rob...@de...> wrote: > Sorry, I thought it was you who was aiming for NSS. I don't think GNUTLS > is all that bad, and given OpenSSL's license issues, it's easily > becoming the most popular not-OpenSSL implementation of SSL. Not to > mention there are plenty of patches around to add SSL support to Jabber > with GNUTLS: Can someone tell me in short words, what are the license issues of openssl? $ rpm -qi openssl (from SuSE Linux 8.2) says: -------------------------------------------------------------------- OpenSSL is based on the excellent SSLeay library developed by Eric A. Young and Tim J. Hudson. The OpenSSL toolkit is licensed under an Apache-style licence which basically means that you are free to get it and to use it for commercial and non-commercial purposes. -------------------------------------------------------------------- So, what's the problem with it? I think, the license issues can not be so dramatically, because so many open-source programs use it. For instance (dependencies from package openssl on my system): =09kdelibs, cups, ghostscript, tcpdump, curl, mysql. postgresql, =09qpopper. openhcbi, heimdal, xchat, openldap2, =09bonobo-activation, libgnomeprint, pine, kdebase, w3m, =09fetchmail and much more... Gaim already uses licenses other that GPL. For instance, if I install the package graphviz which is necessary for Gaim's doxygen docs I get an E-Mail about license issues for this package: -------------------------------------------------------------------- =2E.. Please note that that the graphviz package is distributed under a license from AT&T Research Labs which can be found on http://www.research.att.com/sw/tools/graphviz/license http://www.research.att.com/sw/tools/graphviz/license/minterms.html http://www.research.att.com/sw/tools/graphviz/license/binary.html http://www.research.att.com/sw/tools/graphviz/license/faq.html and also can be read in the files LICENSE.html and MINTERMS.txt in the directory /usr/share/doc/packages/graphviz/ . Recipients of graphviz need to agree with the terms specified in the licens= e files. If they don't, they are not allowed to use this package and we'd recommend un-installing it. =2E.. -------------------------------------------------------------------- I don't know the differences between openssl, gnutls, mozilla-nss from programmers point of view. But from user's point of view, it's easier to install a program which depends from openssl that a program which depends from mozilla-nss. For instance, SuSE Linux 8.2 doesn't have a mozilla-nss package. So it's necessary to install mozilla and mozilla-devel (together 44 Mbyte) for mozilla-nss support on this plattform. Some times ago I tested mozilla-nss binary packages from http://www.mozilla.org/. But, as far as I remember this wasn't a good idea. Bj=F6rn |
From: Robert M. <rob...@de...> - 2003-08-31 13:50:04
|
On Sun, 2003-08-31 at 14:27, Bjoern Voigt wrote: > Can someone tell me in short words, what are the license issues of > openssl? >snip irrelevant wiffle< OpenSSL is licensed with a so-called 4-clause BSD license. The 4th clause requires that you acknowledge the authors of the software in advertising and literature pertaining to products which make use of the OpenSSL code. Gaim is licensed with an unmodified GNU GPL License, version 2, which allows, with certain restrictions, free use of the code to modify, redistribute, etc. One of these restrictions is that the GPL'd code must not be linked with code under licenses that place further restrictions on the software. Such as the advertising clause. So it violates Gaim's license to link it against OpenSSL, and even if we wanted to, it's not possible for us to contact all of the contributors to Gaim to have an exception placed in Gaim's license. For more information see the archives of the debian-level mailing list at http://lists.debian.org/debian-legal/, where this issue has been discussed thousands of times. > Bjoern Regards, Rob |
From: Christian H. <ch...@gn...> - 2003-08-31 18:43:33
|
On Sun, Aug 31, 2003 at 03:27:59PM +0200, Bjoern Voigt wrote: > Gaim already uses licenses other that GPL. For instance, if I install > the package graphviz which is necessary for Gaim's doxygen docs I get > an E-Mail about license issues for this package: >=20 > -------------------------------------------------------------------- > ... > Please note that that the graphviz package is distributed under a license > from AT&T Research Labs which can be found on > http://www.research.att.com/sw/tools/graphviz/license > http://www.research.att.com/sw/tools/graphviz/license/minterms.html > http://www.research.att.com/sw/tools/graphviz/license/binary.html > http://www.research.att.com/sw/tools/graphviz/license/faq.html > and also can be read in the files LICENSE.html and MINTERMS.txt > in the directory /usr/share/doc/packages/graphviz/ . >=20 > Recipients of graphviz need to agree with the terms specified in the lice= nse > files. If they don't, they are not allowed to use this package and we'd > recommend un-installing it. > ... > -------------------------------------------------------------------- No, we don't. Nothing links to it. dot is simply called, and not by anthing gaim-related. That's a Doxygem <-> dot thing. Christian --=20 Christian Hammond <> The GNUpdate Project ch...@gn... <> http://www.gnupdate.org/ If you're not confused, you're not paying attention. |
From: Ludovic L. <ll...@us...> - 2003-10-02 17:22:40
|
Hello list, I've just updated( http://sourceforge.net/tracker/index.php?func=detail&aid=777300&group_id=235&atid=300235 ) a patch to add support for Trillian SecureIM protocol. This new version of the patch uses libgcrypt and allows receiving / (and now) sending messages encrypted with Trillian's SecureIM. - Receiving encrypted messages is unconditionnaly enabled (no UI interface, yet) - Sending encrypted messages is only possible if the other party initiated the communication (and sent the first key-negociation packet) [Initiating the negociation from Gaim is possible to implement but not really needed by me] SecureIM is an encryption protocol sitting on the top of Oscar (ICQ, AIM), and is generally not regarded as very secure (it uses Diffie-Hellman (DH) for negotiating the encryption key, which is prone to a man-in-the-middle attack. It uses blowfish for encryption). That's one reason this patch didn't make it in gaim's CVS, in order not to fool people with a false/weak sense of security. Moreover, this implementation is very simplistic, and only exists for interoperation with existing Trillian users. It's enough for me. I haven't tested with the recent Trillian 2.0 messenger. Best regards, Ludovic LANGE |