Opened 12 years ago

Last modified 3 years ago

#499 new rejected_patch

Extended aim_userinfo_t (user client detection, icqinfo.crap unfolding)

Reported by: uj2 Owned by: MarkDoliner
Milestone: Component: ICQ
Version: 2.0 Keywords:
Cc:

Description

This patch adds ICQ client detection (still in testing stage, but seems to work), and icqinfo.crap array unfolded to dcinfo struct. Client detection code is almost pure rewrite of miranda-im/protocols/IcqOscarJ/icq_clients.c, which is under GPL. Direct-connection info block structure got from http://iserverd.khstu.ru/oscar/info_block.html. One more thing added is aim_userinfo_t::othercaps, which contains raw unrecognized capabilities (needed by client detection code) and supporting code for it.

Attachments (1)

pidgin-fingerprint.patch (28.9 KB) - added by uj2 12 years ago.

Download all attachments as: .zip

Change History (16)

Changed 12 years ago by uj2

comment:1 Changed 12 years ago by nosnilmot

  • Owner set to MarkDoliner

comment:2 Changed 12 years ago by MarkDoliner

  • Type changed from enhancement to patch

comment:3 Changed 12 years ago by seanegan

  • Milestone set to 2.1.0

Mark, I'm targeting this to 2.1.0 just because fast turn-around on patches is good, and apparently this code is already pretty well tested in Miranda. It has a bunch of new strings, so if you can't get it reviewed by tonight (8 July), just bump it to 2.1.1

comment:4 Changed 12 years ago by MarkDoliner

  • Milestone changed from 2.1.0 to 2.1.1

comment:5 Changed 11 years ago by seanegan

  • Milestone changed from 2.1.1 to 2.1.2

comment:6 Changed 11 years ago by seanegan

  • Component changed from libpurple to ICQ

comment:7 Changed 11 years ago by tjod

Hello!

i'm not able to apply this patch into 2.3.1. source, it seems it is written for gaim(?) any idea how to solve it?

comment:8 Changed 11 years ago by datallah

I haven't looked at everything in detail, but this appears to leak in aim_client_miranda_version_unpack().

Mark, this has been sitting around for quite a while; what are your thoughts on including this?

comment:9 Changed 11 years ago by deryni

Assuming I am interpreting this correctly, I don't like this sort of hackish guessing based on advertised (non-standard) capabilities, but that's just me.

comment:10 Changed 11 years ago by MarkDoliner

I haven't looked at the patch. I'm ok with the basic idea... but it doesn't seem like we gain anything from it.

comment:11 Changed 11 years ago by datallah

Right, I don't see any particularly useful benefit from the additional information. It seems to me that we should either accept it or decide not to and move it to the rejected_patches section. I have no opinion on which of these happens.

comment:12 Changed 11 years ago by tjod

if i got this right, this patch should be able to detect client and version of buddys in list. I can see a benefit - eg. file transfers ICQ6<->Pidgin doesn't work for me, so if i can see that other side uses ICQ 6, i would not bother starting transfer...

comment:13 Changed 11 years ago by deryni

The patch doesn't "detect" anything, it has a list of "known" capability data that clients tend to send and does a brute force match against them. This is trivially fakeable by any client that wants to do so and the fact that file transfer fails in that case is a bug and not something we should require users to know about and work around.

comment:14 Changed 11 years ago by AZ

it seems that there are different opinions on whether this is useful or not. such stuff is probably implemented best as a plugin if at all. I don't know whether it is possible to have this implemented as a plugin?

comment:15 Changed 10 years ago by rekkanoryo

  • Type changed from patch to rejected_patch

It seems pretty clear to me that we're not interested in this patch. No sense in it staying on the radar. For the off chance that someone might actually care about this information, I'll leave this ticket open in the rejected_patch ticket type.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!