pidgin: 661db628: http://dev.aol.com/aim/oscar/ says, "A
zacwest at gmail.com
Mon Nov 9 13:58:29 EST 2009
On Thu, Nov 5, 2009 at 03:21, Mark Doliner <mark at kingant.net> wrote:
> On Wed, Nov 4, 2009 at 11:25 PM, Richard Laager <rlaager at wiktel.com>
> > On Wed, 2009-11-04 at 17:21 -0500, markdoliner at pidgin.im wrote:
> >> http://dev.aol.com/aim/oscar/ says, "All strings in Feedbag are UTF8
> >> encoded." So stop trying to validate stuff as utf8 then salvage when
> >> it isn't and just display broken crap or crash.
> > This seems like a bad idea. If we can really crash on invalid data, this
> > is going to be our next security issue.
> Yeah, maybe. It would only be invalid date in your own roster, which
> wouldn't be considered a security issue because it isn't remotely
> exploitable (although it would be a nuisance to any person who is
> affected). I wondered if there is some possibility of non-utf8 in an
> ICQ friend request, but these changes don't affect that.
The latest Adium beta is running with these changes, and we're seeing a fair
amount of bug reports for crashing due to the change. Perhaps a little
further reaching amount of invalid data than expected?
Unless the crash we're seeing is different (but I don't think it is, seems
like this change). Here's an example backtrace:
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 libSystem.B.dylib 0x91161990 strlen + 16
1 ...s.openspecies.rtool.libglib 0x005ec10d g_utf8_collate_key + 416
2 libpurple 0x0071d015 purple_find_group + 102
3 libpurple 0x0085f046 purple_ssi_parselist + 1818
4 libpurple 0x0083dbba parsedata + 574
5 libpurple 0x0083f38c snachandler + 132
6 libpurple 0x0084dbac parse_snac + 239
7 libpurple 0x0084de20 parse_flap + 153
8 libpurple 0x0084e18b flap_connection_recv + 832
9 libpurple 0x0084e1fc flap_connection_recv_cb_ssl + 23
10 libpurple 0x0076c003 recv_cb + 43
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel