mxit libpurple protocol

[Ethan Blanton]

Andrew Victor spake unto us the following wisdom:
> I committed patches for the following issues so far:

All: to clarify, he means he committed to:

    ssh://hg@hg.pidgin.im/private/talos-2016-04-14

> TALOS-CAN-0141        -- Validate mood
> TALOS-CAN-0134        -- Table markup - g_strsplit
> TALOS-CAN-0133        -- Table markup - missing required fields
> TALOS-CAN-0128        -- Splash screen
> TALOS-CAN-0118        -- Stage 3 read error

OK, great start!  These patches look sane to me at a glance, but I
have not thoroughly reviewed them.

purple_escape_filename is terrible, by the way, I hope we've fixed
that to be reentrant for 3.0.

> TALOS-CAN-0122 is a deficiency in way the the Mxit client protocol is
> currently designed.
> It affects all released versions of Mxit, on all platforms.  Therefore this
> issue cannot be "fixed" by making a libPurple/Pidgin change.

That is unfortunate.  However, it is what it is.

Ethan

> 
> Regards,
>   Andrew Victor
> 
> 
> 
> 
> 
> 
> On Fri, Apr 15, 2016 at 5:28 PM, Ethan Blanton <elb at pidgin.im> wrote:
> 
> > Andrew Victor spake unto us the following wisdom:
> > > Great, I got it.
> > >
> > > How do we proceed?
> > > I assume you don't want fixes for these pushed into the mercurial repo
> > > right now.
> >
> > No!  We'll have to do a coordinated release for this.
> >
> > I'm not 100% sure what our plan is going to be for private releases
> > now that we're primarily managing repositories on bitbucket; we still
> > have a private repo on hg.pidgin.im, but probably we're not going to
> > use it.  We'll have to discuss that.
> >
> > In the meantime, I would suggest committing one patch per directory in
> > the repository I sent you, and dropping a note to security at pidgin.im.
> > That lets us figure out process in parallel with getting the bugs
> > fixed.
> >
> > This isn't our only pending security notification right now (although
> > it's the worst), so I imagine we'll be pushing a 2.11 Soon.  Changes
> > to the 3.0 tree are (in my opinion) not as important, as "regular
> > users" shouldn't be exposed to those bugs; let's get the 2.x.y tree
> > fixed up, then port forward to 3.0 once there's a coordinated release.
> >
> > Ethan
> >