[ICQ/AIM] Possibly fix for broken privacy lists in some accounts (tickets #9034, #12549)

[dustin]

Mark Doliner wrote:
> On Mon, Nov 22, 2010 at 9:31 AM, dustin <dzlists at arcor.de> wrote:
>> On 22.11.2010 10:34, Mark Doliner wrote:
>>> On Mon, Oct 18, 2010 at 2:51 PM,  <dzlists at arcor.de> wrote:
>>>> *snip*
>>>> I couldn't find any remnants of the broken bid in the itemlist nor in the tlvlist loaded by
>>>> parsedata() (family_feedbag.c).
>>>>
>>>> Anyway, just deleting the broken entry from the server worked. *snip*
>>>> In this way, it was possible to repair the broken ICQ accounts *snip*
>>> I don't think I followed this... Are you saying that certain items in
>>> the buddy list are "broken"?  What indicates that an item is broken?
>> "Broken" in the sense that there seems to be an item stored on the
>> server which does not appear in the client's ssi itemlist (or the
>> corresponding tlvlist 0x00c8).
>>
>> This causes a "Cannot add buddy..." error when libpurple tries to use
>> the same (gid, bid) combination when adding a blocking/visible/invisible
>> entry. (likely the same bug as described in tickets #9034, #12549, #12933)
>>
>> I'm assuming there's actually a broken entry on the server because:
>>
>> 1. It's only a single (gid, bid) combination that doesn't work, the bids
>> before and after work fine.
>>
>> 2. After sending a delete (SNAC_SUBTYPE_FEEDBAG_DEL) for this (gid, bid)
>> the error will disappear. (However i've no idea if there's any relevant
>> data that gets deleted by this.)
> 
> Ahhh, I see now.  So you're saying that this broken entry doesn't
> appear in OscarData->ssi.official or OscarData->ssi.local?  I wonder
> if that's a server bug (they fail to send us an entry for that
> gid+bid), or a client bug (we receive the entry for that gid+bid, but
> we discard it for some reason).
>

I guess it's the server, because the entry does not appear even when
reading directly from the tlvlist. (using the patch I posted on 13.11.)
AFAICS there's no filtering before that.

Example:
(23:25:24) oscar: Reading items from tlvlist for account xxxxxxxxx:
gid=0x0000  bid=0x0000  list_type=0x0001  name=(null)      [Group]
gid=0x0000  bid=0x0001  list_type=0x0004  name=(null)      [PDInfo]
gid=0x0000  bid=0x0002  list_type=0x0005  name=(null)      [PresencePrefs]
gid=0x0000  bid=0x0003  list_type=0x0020  name=ICQ-MDIR    [ICQ-MDir]
gid=0x0000  bid=0x0004  list_type=0x0014  name=1           [Buddy Icon]
gid=0x0000  bid=0x0005  list_type=0x001d  name=(null)      [Vanity Info]
gid=0x0000  bid=0x0007  list_type=0x0019  name=yyyyyyyyy   [Non-Buddy]
gid=0x0000  bid=0x0009  list_type=0x0029  name=facebook    [Facebook]
..
(23:26:53) oscar: ssi: About to add a deny
(23:26:53) oscar: Adding item gid=0x0000  bid=0x0006  list_type=0x000e
name=yyyyyyyyy   [ICQDeny/Ignore]  (data: 0 bytes).
(23:26:54) oscar: ssi: status is 0x0003 for a 0x0008 action with name no item
(23:26:54) oscar: ssi: Action 0x0008 was unsuccessful with error 0x0003

>> [..]
>> This seems to be a rare bug, and having an automatic correction for this
>> may have harmful side effects (possibly deleting legitimate entries in a
>> different situation...).
>>
>> So I thought keeping a manual fix for this, and preferably far away
>> from libpurple's normal functioning, would be better.
> 
> Hrm.  Good point.  I guess we should determine if this is a client bug
> (make sure we're not discarding the entry for some reason).  If it's
> not a client bug, then I'd argue that we SHOULD include code to
> automatically correct the problem.  I think it happens frequently
> enough, and the downside of possibly deleting a single item is minor
> enough to justify it.

Maybe this could be done in purple_ssi_parseack() [oscar.c] as part of
error handling?
e.g.
in aim_ssi_sync(): save the last addition to the item list in some place if
gid == 0.
in purple_ssi_parseack(): if error is 0x0003 and item does not exist in the
itemlist => delete (or give a special dialog window?)

> Although I wonder, do official ICQ clients have this same problem?
> How do they work around it?

Ignoring the problem. ;-)
It seems like only libpurple uses bids in ascending order, others have some
kind of randomization...

(01:40:27) dump: gid=0x0000 bid=0x2180 list_type=0x0003	name='xxxxxxxxx'
(01:40:27) dump: gid=0x0000 bid=0x21e2 list_type=0x0003	name='yyyyyyyyy'
(01:40:27) dump: gid=0x0000 bid=0x7d8c list_type=0x0003	name='zzzzzzzzz'

(These are invisible entries from Miranda, but ICQ7 and qip look similar.)


Regards,

Dustin