[mICQ] ICQ md5 login support

[Rüdiger Kuhlmann]

>--[Robert Bartel]--<r.bartel at gmx.net>
> On Mon, Apr 23, 2007 at 00:02:36 +0200, Rüdiger Kuhlmann wrote:
> > So I applied your changes after abstracting the md5 calls away; if OpenSSL
> > is compiled in, it will use the md5 functions from OpenSSL, if GnuTLS is
> > compiled in, it will use the md5 functions from libgcrypt, in the
> > autopackage it will use the functions from libgcrypt if is is available,
> > and otherwise use the old login method.
> Great - now it can be used with OpenSSL and libgcrypt. I was looking in GnuTLS
> and found only the md5 compatibility functions in <gnutls/openssl.h>.

Yes, but they're in an extra library, which may or may not be available,
while using them from gcrypt means no extra library as GnuTLS depends
on gcrypt anyway.

> Never heard of autopackage.

It's a pretty dead project that allowed to create self-extracting
installers. It's most weak point, except for maintainer attitude, is the
pita that installation of the autopackage tools is. One good thing that came
out of the project is binary relocation support.

> Is it intentional that there is no support for OpenSSL with that?

Well, basically a program is compiled normally, however, function calls to a
given set of libraries are relayed through stubs actually checking the
libraries existance (and aborting otherwise), loading the library and then
calling the actual function. Additionally, some external variables are
declared that can be used to check the existance without aborting.

So basically the autpackage is created from the same sources with some magic
behind the scenes. Of course, you can't link against GnuTLS and OpenSSL at
the same time. Well, at least not without doing some rearrangements. So I
chose GnuTLS.

> Something else I noticed: the language and country codes used in the login
> packet are the constant strings "de" and "DE". Don't know if that's a good
> idea - could be used to detect and lock out micq clients by the login server?

mICQ sends a specific capability. There's nothing easier than singling it
out from that. Also de/DE is a pretty valid combination for everyone using
it from Germany. So no, I'd say that risc is neglectable.

> With the attached patch they are adapted to the current locale, or "en" "us"
> as fallback. Has no real benefit, only decoration.

There's also nl_langinfo (_NL_ADDRESS_COUNTRY_AB2) and
nl_langinfo (_NL_ADDRESS_LANG_AB), which might be some more official source
of the correct values. Unfortunately, the latter is often not set in locale
definitions, and I couldn't find any case where it is different from what
you used. Also, why fall back to en/us?

> Also I'm not understanding the last TLV in that packet, doesn't micq use the
> server side information (SSI) for the contact list?

No, not quite. It compares it with its local list, but otherwise ignores it.
Result: the possibility to add contacts without authorization.

> So maybe it should be 1 and not 0? While experimenting I left it away, and
> the server didn't care - could still login successfully. The patch
> comments it out - might be useful for testing.

You could try to check whether it makes a difference for contacts that you
never authorized...

-- 
"See, free nations are peaceful nations. Free nations don't attack
 each other. Free nations don't develop weapons of mass destruction."
      - George W. Bush, Milwaukee, Wis., Oct. 3, 2003