Opened 4 years ago

Closed 4 years ago

#15286 closed defect (fixed)

Master bug for old libraries in Windows Pidgin build

Reported by: ioerror Owned by: datallah
Milestone: 2.10.7 Component: winpidgin (gtk)
Version: 2.10.6 Keywords: security
Cc:

Description

I found at least two (#15284 #15285) libraries shipped by pidgin, in addition to the GTK bundle (#14571) that appear to be very old and likely contain known vulnerabilities.

I hacked up a quick dump of the libraries and their apparent compile date. Some of the things I've put in bold appears dangerously old - though basically everything in this list not from pidgin/libpurple seems dangerously old:

exchndl.dll
Time/Date		Mon Mar 15 20:03:18 2010
Time/Date stamp 		4b9ef4f6

freebl3.dll
Time/Date		Sun Feb 28 15:44:10 2010
Time/Date stamp 		4b8affca

libjabber.dll
Time/Date		Fri Jul  6 09:22:55 2012
Time/Date stamp 		4ff70f58

libmeanwhile-1.dll
Time/Date		Tue Dec  9 17:05:10 2008
Time/Date stamp 		4924d12b

libnspr4.dll
Time/Date		Sun Feb 28 15:40:25 2010
Time/Date stamp 		4b8afee9

liboscar.dll
Time/Date		Fri Jul  6 09:22:55 2012
Time/Date stamp 		4ff70f9f

libplc4.dll
Time/Date		Sun Feb 28 15:40:29 2010
Time/Date stamp 		4b8afeed

libplds4.dll
Time/Date		Sun Feb 28 15:40:26 2010
Time/Date stamp 		4b8afeea

libpurple.dll
Time/Date		Fri Jul  6 09:22:56 2012
Time/Date stamp 		4ff70f1a

'''libsasl.dll
Time/Date		Thu Sep 13 16:02:21 2007
Time/Date stamp 		46e9c17d'''

'''libsilc-1-1-2.dll
Time/Date		Tue Dec  2 20:51:36 2008
Time/Date stamp 		49361057'''

'''libsilcclient-1-1-2.dll
Time/Date		Tue Dec  2 20:51:55 2008
Time/Date stamp 		4936106b'''

'''libxml2-2.dll
Time/Date		Mon Sep 14 09:05:21 2009
Time/Date stamp 		4aae69c1'''

libymsg.dll
Time/Date		Fri Jul  6 09:22:56 2012
Time/Date stamp 		4ff70fb9

'''nss3.dll
Time/Date		Sun Feb 28 15:45:49 2010
Time/Date stamp 		4b8b002d'''

'''nssckbi.dll
Time/Date		Sun Feb 28 15:46:28 2010
Time/Date stamp 		4b8b0054'''

'''nssutil3.dll
Time/Date		Sun Feb 28 15:42:06 2010
Time/Date stamp 		4b8aff4e'''

pidgin.dll
Time/Date		Fri Jul  6 09:22:56 2012
Time/Date stamp 		4ff7104d

smime3.dll
Time/Date		Sun Feb 28 15:46:15 2010
Time/Date stamp 		4b8b0047

softokn3.dll
Time/Date		Sun Feb 28 15:44:17 2010
Time/Date stamp 		4b8affd1

sqlite3.dll
Time/Date		Sun Feb 28 15:42:00 2010
Time/Date stamp 		4b8aff48

'''ssl3.dll
Time/Date		Sun Feb 28 15:46:02 2010
Time/Date stamp 		4b8b003a
'''}}}

Change History (31)

comment:1 Changed 4 years ago by ioerror

I think each library should be triaged - as an example...

It appears that libsasl.dll is likely remotely exploitable ala CVE-2009-0688: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-0688

comment:2 Changed 4 years ago by ioerror

  • libxml2-2.dll seems to be vulnerable - see #15284
  • nss3.dll seems to be vulnerable - see #15284

comment:3 Changed 4 years ago by DrWhax

It seems that libsilc-1-1-2.dll & libsilcclient-1-1-2.dll are vulnerable to http://www.cvedetails.com/cve/CVE-2008-7160/ & http://www.cvedetails.com/cve/CVE-2009-3163/

comment:4 follow-up: Changed 4 years ago by ioerror

Ok - so grouping by CVE/known vulns this time.

Everything related to GTK is covered in #14571, #15281 and perhaps #15282

libnss (#15284) appears vulnerable it is responsible ( http://developer.pidgin.im/static/win32/nss-3.12.5-nspr-4.8.2.tar.gz ) for these dlls:

freebl3.dll
libnspr4.dll
libplc4.dll
libplds4.dll
nss3.dll
nssckbi.dll
nssdbm3.dll
nssutil3.dll
smime3.dll
softokn3.dll
sqlite3.dll
ssl3.dll

CMU Cyrus SASL library is likely remotely exploitable (CVE-2009-0688):

libsasl.dll

The Unofficial Lotus Sametime Community Client Library aka libmeanwhile is provided by meanwhile-1.0.2_daa2 ( http://developer.pidgin.im/static/win32/meanwhile-1.0.2_daa2-win32.zip ) and it appears to not have any outstanding CVEs. I did however find a debian bug from 2011 ( http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652156 ) that indicates that the build from 2008-12-09 also has issues:

libmeanwhile-1.dll

libsilc is vulnerable (CVE-2009-3163 and CVE-2008-7160):

libsilc-1-1-2.dll
libsilcclient-1-1-2.dll

libxml2 is seemingly vulnerable to a bunch of CVEs:

libxml2-2.dll

exchndl.dll appears to be the Crash Reporting Library ( http://developer.pidgin.im/static/win32/pidgin-inst-deps-20100315.tar.gz). I think the source for that dll is from http://pidgin.im/~datallah/exchndl.c - is that the code for the exception handler/Crash Reporter? If so, is it actually free software? Either way - according to the author of MSJExceptionHandler, it was replaced by WheatyExceptionReport? ( http://www.wheaty.net/Columns.htm ) in 2002 ( http://bwmangos.googlecode.com/svn/trunk/src/shared/WheatyExceptionReport.cpp ). Furthermore, it appears that it is pretty unsafe in general:

exchndl.dll

The following are Pidgin/libpurple code (including plugins/*) and not thought to be covered by any CVEs - though I guess I'll wait for explicit confirmation from the pidgin team, as they're the authority on these dlls:

libjabber.dll
liboscar.dll
libpurple.dll
libymsg.dll
pidgin.dll

comment:5 in reply to: ↑ 4 ; follow-ups: Changed 4 years ago by datallah

Replying to ioerror:

exchndl.dll appears to be the Crash Reporting Library ( http://developer.pidgin.im/static/win32/pidgin-inst-deps-20100315.tar.gz). I think the source for that dll is from http://pidgin.im/~datallah/exchndl.c - is that the code for the exception handler/Crash Reporter? If so, is it actually free software? Either way - according to the author of MSJExceptionHandler, it was replaced by WheatyExceptionReport? ( http://www.wheaty.net/Columns.htm ) in 2002 ( http://bwmangos.googlecode.com/svn/trunk/src/shared/WheatyExceptionReport.cpp ). Furthermore, it appears that it is pretty unsafe in general:

exchndl.dll

Yes, that's the crash report generator. It isn't actually MSJExceptionHandler, but I guess that was an inspiration or something.

It is LGPL - it's from http://code.google.com/p/jrfonseca/ - it's part of drmingw. It's been modified somewhat to suite our needs.

What are your specific complaints about it being unsafe?

The following are Pidgin/libpurple code (including plugins/*) and not thought to be covered by any CVEs - though I guess I'll wait for explicit confirmation from the pidgin team, as they're the authority on these dlls:

libjabber.dll
liboscar.dll
libpurple.dll
libymsg.dll
pidgin.dll

These are all part of the libpurple and pidgin codebase and are built from the pidgin codebase during each release.

comment:6 in reply to: ↑ 5 Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

exchndl.dll appears to be the Crash Reporting Library ( http://developer.pidgin.im/static/win32/pidgin-inst-deps-20100315.tar.gz). I think the source for that dll is from http://pidgin.im/~datallah/exchndl.c - is that the code for the exception handler/Crash Reporter? If so, is it actually free software? Either way - according to the author of MSJExceptionHandler, it was replaced by WheatyExceptionReport? ( http://www.wheaty.net/Columns.htm ) in 2002 ( http://bwmangos.googlecode.com/svn/trunk/src/shared/WheatyExceptionReport.cpp ). Furthermore, it appears that it is pretty unsafe in general:

exchndl.dll

Yes, that's the crash report generator. It isn't actually MSJExceptionHandler, but I guess that was an inspiration or something.

Ok but is the code http://pidgin.im/~datallah/exchndl.c or something else? http://code.google.com/p/jrfonseca/downloads/detail?name=drmingw-0.4.4.zip doesn't appear to have any source code beyond drmingw-0.4.4/samples/test.c, which is an example:

 % unzip drmingw-0.4.4.zip 
Archive:  drmingw-0.4.4.zip
  inflating: drmingw-0.4.4/COPYING   
  inflating: drmingw-0.4.4/COPYING.LIB  
  inflating: drmingw-0.4.4/drmingw.exe  
  inflating: drmingw-0.4.4/doc/drmingw.html  
  inflating: drmingw-0.4.4/doc/drmingw.reg  
  inflating: drmingw-0.4.4/doc/exception-nt.gif  
  inflating: drmingw-0.4.4/doc/install.gif  
  inflating: drmingw-0.4.4/doc/sample.gif  
  inflating: drmingw-0.4.4/samples/test.c  
  inflating: drmingw-0.4.4/samples/test.exe  
  inflating: drmingw-0.4.4/samples/testcpp.cxx  
  inflating: drmingw-0.4.4/samples/testcpp.exe  

It is LGPL - it's from http://code.google.com/p/jrfonseca/ - it's part of drmingw. It's been modified somewhat to suite our needs.

I looked and found this: http://code.google.com/p/jrfonseca/source/browse/exchndl.c?repo=drmingw

Is that the actual code used? And if so... Is the patch exchndl_daa4.diff from pidgin-inst-deps-20100315.tar.gz what is applied on top of it?

What are your specific complaints about it being unsafe?

The following are Pidgin/libpurple code (including plugins/*) and not thought to be covered by any CVEs - though I guess I'll wait for explicit confirmation from the pidgin team, as they're the authority on these dlls:

libjabber.dll
liboscar.dll
libpurple.dll
libymsg.dll
pidgin.dll

These are all part of the libpurple and pidgin codebase and are built from the pidgin codebase during each release.

That's what I thought. I assume these are up to date and have no outstanding security issues. Is that correct?

comment:7 in reply to: ↑ 5 Changed 4 years ago by ioerror

Replying to datallah:

What are your specific complaints about it being unsafe?

I've opened a bug about exchndl.dll in #15289 - depending on the local changes pidgin makes, they may not apply or it may be made worse. It might also be nothing.

comment:8 follow-ups: Changed 4 years ago by datallah

Why are all of these being posted publicly?

comment:9 in reply to: ↑ 8 ; follow-up: Changed 4 years ago by ioerror

Replying to datallah:

Why are all of these being posted publicly?

I didn't realize it was important to keep these well know issues a secret. There was no problem discussing these kinds of issues in #14571 - how are these issues different? It's more third party library code that isn't maintained, just like the GTK bundle, right?

Every single issue, other than #15289 (which is not confirmed as anything interesting anyway) is discussing known vulnerabilities.

comment:10 in reply to: ↑ 8 ; follow-up: Changed 4 years ago by abadidea

Replying to datallah:

Why are all of these being posted publicly?

the ticket that ioerror opened for "all the DLLs are out of date" (#15281) was closed as a duplicate of #14571 which was opened just about a year ago.

This isn't 0day, this is nday for very high values of n :)

comment:11 in reply to: ↑ 9 Changed 4 years ago by datallah

Replying to ioerror:

Replying to datallah:

Why are all of these being posted publicly?

I didn't realize it was important to keep these well know issues a secret. There was no problem discussing these kinds of issues in #14571 - how are these issues different? It's more third party library code that isn't maintained, just like the GTK bundle, right?

Every single issue, other than #15289 (which is not confirmed as anything interesting anyway) is discussing known vulnerabilities.

Is it not a common practice to keep security issues private until they're resolved?

It is no different than #14571, I should have said something sooner. I figured the cat was out of the bag already because it was posted; I didn't realize you were going to keep going.

Sure they're "known" vulnerabilities in the library that they exist in, but they're not "known" in Pidgin.

comment:12 in reply to: ↑ 10 ; follow-up: Changed 4 years ago by datallah

Replying to abadidea:

Replying to datallah:

Why are all of these being posted publicly?

the ticket that ioerror opened for "all the DLLs are out of date" (#15281) was closed as a duplicate of #14571 which was opened just about a year ago.

Right, that ticket also shouldn't have been opened either, but it wasn't a real problem anyway.

The instructions on the top of the ticket page link to TipsForBugReports which has instructions about how to deal with security issues.

This isn't 0day, this is nday for very high values of n :)

Like I said, it is not known information about Pidgin.

comment:13 Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

Replying to datallah:

Why are all of these being posted publicly?

I didn't realize it was important to keep these well know issues a secret. There was no problem discussing these kinds of issues in #14571 - how are these issues different? It's more third party library code that isn't maintained, just like the GTK bundle, right?

Every single issue, other than #15289 (which is not confirmed as anything interesting anyway) is discussing known vulnerabilities.

Is it not a common practice to keep security issues private until they're resolved?

They are resolved issues in the respective code base. Clearly, if I am correct, Pidgin doesn't ship those fixes and obviously, that is a problem worth resolving. Is there a bug tracking option that allows me to mark bugs as private or secret? If not, I guess that might be a problem.

I wasn't aware that I should treat these as a secret. As I said, #14571 demonstrates a total disregard for common security practices and it seemed to indicate that this kind of stuff wasn't worth keeping secret. I'm happy to put things out in the open - sunlight tends to disinfect...

It is no different than #14571, I should have said something sooner. I figured the cat was out of the bag already because it was posted; I didn't realize you were going to keep going.

Yeah, the Pidgin team does seem to have people report things and then for some reason, they vanish. I think it might be induced by the kinds of conversations that result from trying to help? I stated that I wanted to help and I was met with cold resistance, seemingly callous arrogance and intense argument.

Still, I went through every library in the shipping Windows build. I followed pidgin's lead on the secrecy angle and I found an issue in almost every single shipping library. If the GTK bundle was fair game for open discussion, I hardly see how older vulnerabilities are somehow not fair game for open discussion.

Sure they're "known" vulnerabilities in the library that they exist in, but they're not "known" in Pidgin.

Oh - that is just the point, it's all well known. Frustratingly so, I might add.

Pidgin is well know as being a security joke. The pidgin team has a reputation that it doesn't seem to care about user security; I hope that we can prove both of those things to be incorrect.

The windows version is remotely exploitable from a dozen angles as I've shown here. This isn't even starting to touch on libpurple, pidgin or finch; nor does it address the 0day sitting around in a few of the libraries that libpurple uses. Those issues can go into other bugs as this bug is just about old buggy third party code.

comment:14 in reply to: ↑ 12 ; follow-up: Changed 4 years ago by ioerror

Replying to datallah:

Replying to abadidea:

Replying to datallah:

Why are all of these being posted publicly?

the ticket that ioerror opened for "all the DLLs are out of date" (#15281) was closed as a duplicate of #14571 which was opened just about a year ago.

Right, that ticket also shouldn't have been opened either, but it wasn't a real problem anyway.

I think pidgin should get a security tag that actually makes the bugs private, perhaps?

The instructions on the top of the ticket page link to TipsForBugReports which has instructions about how to deal with security issues.

Ok - well, if I find any novel 0day, I'll drop it an a private message. I didn't think that shipping old buggy libraries, as I said, counted.

This isn't 0day, this is nday for very high values of n :)

Like I said, it is not known information about Pidgin.

Pidgin is known to have a pretty bad security reputation and I am doubtful that I am the first to find any of these issues. As we saw in #14571, some guy's automated security software actually finds these kinds of bugs in the pidgin software releases. I feel like such a a sucker, I had to slum it with objdump...

comment:15 in reply to: ↑ 14 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

I think pidgin should get a security tag that actually makes the bugs private, perhaps?

This would be nice, but it isn't something that trac supports (at least not well). There are a couple plugins that attempt to do something like this, but they leak the tickets via emails and such and the data would end up in public anyway.

comment:16 in reply to: ↑ 15 ; follow-up: Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

I think pidgin should get a security tag that actually makes the bugs private, perhaps?

This would be nice, but it isn't something that trac supports (at least not well). There are a couple plugins that attempt to do something like this, but they leak the tickets via emails and such and the data would end up in public anyway.

That still seems like an improvement - I mean, it's all plain text at some point. Pidgin doesn't publish a PGP/GPG key on the security contact page, so I assumed that a network sniffing adversary wasn't part of your threat model...

comment:17 in reply to: ↑ 16 Changed 4 years ago by datallah

Replying to ioerror:

Replying to datallah:

Replying to ioerror:

I think pidgin should get a security tag that actually makes the bugs private, perhaps?

This would be nice, but it isn't something that trac supports (at least not well). There are a couple plugins that attempt to do something like this, but they leak the tickets via emails and such and the data would end up in public anyway.

That still seems like an improvement - I mean, it's all plain text at some point. Pidgin doesn't publish a PGP/GPG key on the security contact page, so I assumed that a network sniffing adversary wasn't part of your threat model...

I'm more thinking of the "tracker" mailing list as a problem rather than network sniffing.

comment:18 follow-up: Changed 4 years ago by ioerror

Yeah, that would be a problem, I agree.

So back on topic - any thoughts on the actual bugs here?

comment:19 in reply to: ↑ 18 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

Yeah, that would be a problem, I agree.

So back on topic - any thoughts on the actual bugs here?

I agree that most of these need to be addressed.

  • NSS/NSPR - Looks problematic. We had to build these ourselves for the last update, which was an ordeal, see #11464
  • SASL - Looks problematic. Was also an ordeal to build, but IIRC the work that bvictor did to get NSS building should make it easier to build (if we can find the instructions).
  • meanwhile - there doesn't appear to be anything to go on, there's no backtrace or any details; the library also hasn't been maintained in quite a while
  • SILC - Looks problematic. Also painful to build (there's a pattern emerging)
  • libxml2 - Looks problematic. I've never built it.
  • exchndl - I'll have to look at the other ticket more carefully; pidgin isn't registered as a file handler, so I don't think the LoadLibrary issue is a real problem for us.
  • Pidgin DLLs - There are no unresolved CVEs that we're aware of in these (granted, I wouldn't be disclosing them here if there were :P).

comment:20 in reply to: ↑ 19 ; follow-up: Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

Yeah, that would be a problem, I agree.

So back on topic - any thoughts on the actual bugs here?

I agree that most of these need to be addressed.

  • NSS/NSPR - Looks problematic. We had to build these ourselves for the last update, which was an ordeal, see #11464

Agreed.

  • SASL - Looks problematic. Was also an ordeal to build, but IIRC the work that bvictor did to get NSS building should make it easier to build (if we can find the instructions).

Agreed.

  • meanwhile - there doesn't appear to be anything to go on, there's no backtrace or any details; the library also hasn't been maintained in quite a while

I think it remotely crashed and boy oh boy do we need more information. :)

  • SILC - Looks problematic. Also painful to build (there's a pattern emerging)

Agreed. SILC is basically just a problem.

  • libxml2 - Looks problematic. I've never built it.

Agreed.

  • exchndl - I'll have to look at the other ticket more carefully; pidgin isn't registered as a file handler, so I don't think the LoadLibrary issue is a real problem for us.

When I install it on Windows I see:

URI Handlers [x]
  aim:       [x]
  msnim:     [x]
  myim:      [x]
  xmpp:      [x]

They're all selected by default.

  • Pidgin DLLs - There are no unresolved CVEs that we're aware of in these (granted, I wouldn't be disclosing them here if there were :P).

I'm working on it. :)

comment:21 in reply to: ↑ 20 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

  • exchndl - I'll have to look at the other ticket more carefully; pidgin isn't registered as a file handler, so I don't think the LoadLibrary issue is a real problem for us.

When I install it on Windows I see:

> URI Handlers [x]
>   aim:       [x]
>   msnim:     [x]
>   myim:      [x]
>   xmpp:      [x]

They're all selected by default.

Yes, but the exception handler isn't used in this case, so we're still ok :) See https://bitbucket.org/pidgin/main/src/release-2.x.y/pidgin/win32/winpidgin.c#cl-666

comment:22 in reply to: ↑ 21 ; follow-up: Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

  • exchndl - I'll have to look at the other ticket more carefully; pidgin isn't registered as a file handler, so I don't think the LoadLibrary issue is a real problem for us.

When I install it on Windows I see:

> URI Handlers [x]
>   aim:       [x]
>   msnim:     [x]
>   myim:      [x]
>   xmpp:      [x]

They're all selected by default.

Yes, but the exception handler isn't used in this case, so we're still ok :) See https://bitbucket.org/pidgin/main/src/release-2.x.y/pidgin/win32/winpidgin.c#cl-666

When is that code ever used?

comment:23 Changed 4 years ago by ioerror

It seems to me that the real issue is that Win32 builds should happen from source for all third party libraries. It looks like every third party library for win32 is either old and seemingly abandoned and/or promoting cargo cult build engineering.

In an ideal world, I'd imagine that it makes sense to specifically build pidgin against a given library version for win32 and to have the entire process automated.

comment:24 Changed 4 years ago by mpadams

I'll weigh in: I second ioerror's concerns; the build model for Win32 is unsustainable long term. I managed to compile 2.10.6 with GTK 2.20.1, instead of 2.14: 2.22 & 2.24 would throw random errors. Attempts to update other libraries came to nil: I think whats holding things back, is having to use a specific compiler; I run into that issue trying to compile Android kernels properly.

comment:25 in reply to: ↑ 22 ; follow-up: Changed 4 years ago by datallah

Replying to ioerror:

Replying to datallah:

Yes, but the exception handler isn't used in this case, so we're still ok :) See https://bitbucket.org/pidgin/main/src/release-2.x.y/pidgin/win32/winpidgin.c#cl-666

When is that code ever used?

pidgin.exe is effectively a launcher and has two basic purposes:

  • Set up the environment and launch the Pidgin GTK+ application
    • This is when exchndl.dll is loaded
  • Serve as a simple command line interface to pass messages into the currently running Pidgin instance.
    • This is the case above that the URI handlers use and exchndl.dll isn't used.

comment:26 in reply to: ↑ 25 Changed 4 years ago by ioerror

Replying to datallah:

Replying to ioerror:

Replying to datallah:

Yes, but the exception handler isn't used in this case, so we're still ok :) See https://bitbucket.org/pidgin/main/src/release-2.x.y/pidgin/win32/winpidgin.c#cl-666

When is that code ever used?

pidgin.exe is effectively a launcher and has two basic purposes:

  • Set up the environment and launch the Pidgin GTK+ application
    • This is when exchndl.dll is loaded
  • Serve as a simple command line interface to pass messages into the currently running Pidgin instance.
    • This is the case above that the URI handlers use and exchndl.dll isn't used.

OK. So, I'd say that fixing up exchndl.dll is probably worthwile, even if at the moment, we can't find an obvious way to trigger those bugs in an malicious manner. I'll move my discussion of that into #15289.

comment:27 Changed 4 years ago by DrWhax

Also see #15290

comment:28 Changed 4 years ago by Daniel Atallah <datallah@…>

(In [213ea319f7cd]):
Update silc to 1.1.10 in the win32 build. Refs #15286

comment:29 Changed 4 years ago by Daniel Atallah <datallah@…>

(In [ace2bba864d7]):
Update NSS to 3.13.6 and NSPR to 4.9.2 in the win32 build. Fixes #15284 Refs #15286

comment:30 Changed 4 years ago by Daniel Atallah <datallah@…>

(In [3b55f180e38d]):
Update Cyrus SASL to 2.1.25 in the win32 build. Refs #15286

comment:31 Changed 4 years ago by Daniel Atallah <datallah@…>

  • Milestone set to 2.10.7
  • Resolution set to fixed
  • Status changed from new to closed

(In [8e037a7b4ccd]):
Update various win32 dependencies - the new GTK+ bundle will be called 2.16.6.1 Thanks goes to Dieter Verfaillie for helping get the GTK+ dependencies updated. Fixes #14571, #15285, #15286

  • ATK 1.32.0-2
  • expat 2.1.0-1
  • freetype 2.4.10-1
  • gettext 0.18.1.1-2
  • Glib 2.28.8-1
  • libpng 1.4.12-1
  • Pango 1.29.4-1
  • libxml2 2.9.0-1
  • zlib 1.2.5-2
Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!