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

[dustin]

Hello,


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.)

>> Can such a deletion also be done from a plug-in (e.g. by injecting data into the ssi.official or
>> ssi.pending list of an account)?
>> If so, I would like to write one (if this approach makes any sense at all).
> 
> Plugins don't really have access to internal oscar data structures.
> But if this is something that should be done for all AIM and ICQ buddy
> lists then it seems like the most appropriate place to do it is in
> aim_ssi_cleanlist() in libpurple/protocols/oscar/family_feedbag.c

I think the only way to find those entries is actually receiving an
0x0003 error (item already exists) when trying to add an item.

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.


Regards,

Dustin