[Pidgin] #14571: Win32 installer uses insecure GTK+ version

[Pidgin]

#14571: Win32 installer uses insecure GTK+ version
--------------------+-------------------------------------------------------
 Reporter:  sdierl  |        Owner:  datallah       
     Type:  defect  |       Status:  new            
Milestone:  3.0.0   |    Component:  winpidgin (gtk)
  Version:  2.10.0  |   Resolution:                 
 Keywords:          |  
--------------------+-------------------------------------------------------

Comment(by datallah):

 Replying to [comment:32 ioerror]:

 *SIGH* this is more painful than it should be.
 I feel like I've wasted far too much time replying to this ticket that I
 could have used for something useful.

 > I think you misunderstand. I am not advocating jumping to the git tip of
 their tree. I am advocating jumping to the compatible tip that isn't
 vulnerable to multi-year old bugs. Part of that, I assume, is some bug
 fixing on the GTK/pidgin side. I am by no means making light of that work.

 No, I'm talking about the latest stable GTK+ 2.x version, the same as you,
 not some unreleased version.

 With the exception of CVE-2010-4831, which is not a problem for us
 (whether you believe that or not), none of these issues are in GTK+
 itself, they're all in other third party libraries that are built by the
 GTK+ folks and distributed with GTK+.

 As I've said before, I don't want to upgrade the entire GTK+ stack right
 now unless there is a compelling reason to do so (which I haven't seen)
 because it's likely to cause more serious problems (and who knows, maybe
 introduce more vulnerabilities), so the talk about updating GTK+ is a
 distracting sidenote that you keep bringing back.
 Let's limit the scope of this to talk of updating *SPECIFIC* problematic
 libraries (currently only libpng), and not the whole stack.

 > Yeah, I realize you didn't ask for an exploit. I haven't provided one,
 yet. I provided a malformed png to settle the discussion that it is a
 problem. You actually stated a year ago: ''This isn't an "over the wire"
 vulnerability.'' and so actually, I wouldn't say from the start that this
 was an acknowledged bug. Furthermore, my other bug was closed as dupe,
 even though it points out another handful of CVEs.

 Your other bug was merged with this bug because they both refer to
 potential security issues in the GTK+ stack that we distribute. That
 doesn't make what was said previously in this ticket suddenly apply to all
 of the issues that you mentioned in your other ticket.  You bring back
 what I said a year ago (referring to CVE-2010-4831) out of context as if I
 was talking about the libpng issues; I've already corrected you on this,
 but here it is again.

 > > > > If there are specific issues that necessitate an update (e.g. this
 libpng issue), we can update that particular component (as I'm willing to
 do when we can get a newer official binary), but to update the whole stack
 requires a lot of testing, and I don't foresee having time to do that soon
 (nor do I see a good reason to do so).
 > > >
 > > > Every item with a CVE in #15281 should be assumed to be reachable
 and anything less seems irresponsible. I mean, we're not talking about
 0day here, which pidgin is rumored to have lots of, we're talking about
 600+day vulns here.
 > >
 > > I disagree.  Just because there is a potential issue in a library
 which Pidgin uses doesn't mean that it's a problem for Pidgin's usage of
 the library.
 >
 > This is a mindset that causes a lot of security issues. I agree with you
 in theory. In practice, you'll have to choose between triaging every
 single CVE in a third party library, on a basically unsupported platform
 or you can just assume the worst, which is probably a safe case. So yeah,
 so, pidgin might not be vulnerable to *all of those CVEs* but pidgin would
 be wise to just remove the vulnerable code, rather than trying to figure
 that out. Especially when we consider the sheer number of issues. :(

 Even with this mindset, we should still only be updating particular
 problematic components, not the whole stack.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/14571#comment:34>
Pidgin <http://pidgin.im>
Pidgin