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

[Mark Doliner]

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

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

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.

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

--Mark