Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update libpng and libjpeg in binary builds #544

Closed
totaam opened this issue Mar 21, 2014 · 8 comments
Closed

update libpng and libjpeg in binary builds #544

totaam opened this issue Mar 21, 2014 · 8 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Mar 21, 2014

Issue migrated from trac ticket # 544

component: platforms | priority: major | resolution: fixed

2014-03-21 08:37:22: totaam created the issue


We don't use libpng or libjpeg all that much, most of the picture format parsing is done using Pillow, but there are still codepaths that rely on GTK for parsing (ie: window icons), and GTK uses those libraries. In some recent OSX builds, Pillow had gone missing because of packaging issues (see #500#comment:16), which means that we ended up using the GTK fallback.

The problem is that there are many security issues in libpng (and probably also in libjpeg), just look at the libpng home page which is full of CVE entries... So all in all, it isn't too difficult for a hostile server to use PNG or JPEG to attack the client.

For OSX, it isn't too bad, we can probably bump the libpng version in the moduleset (see #533), but for win32... building (Py)GTK from source is very hard, and updating the libpng14-14.dll in place may not be possible.. Ouch! One way to solve this is #300 ("setup a proper build infrastructure for win32 builds")

libjpeg seems to very very slow at making new releases, so maybe we can switch to one of those instead (assuming that those are API compatible):

@totaam
Copy link
Collaborator Author

totaam commented Mar 21, 2014

2014-03-21 11:16:06: totaam edited the issue description

@totaam
Copy link
Collaborator Author

totaam commented Mar 21, 2014

2014-03-21 11:16:06: totaam commented


I've bumped by OSX build to libpng-1.6.10 as part of testing for #533 and it seems to work fine, libjpeg can probably be bumped the same way. So OSX isn't too much of a problem.

win32 on the other hand...

@totaam
Copy link
Collaborator Author

totaam commented Mar 27, 2014

2014-03-27 04:46:29: totaam commented


I've updated my OSX build environment with:

  • libjpeg-turbo-1.3.1
  • tiff-4.0.3
  • libpng-1.6.10

Then:

  • rebuild gdk-pixbuf:
jhbuild buildone -f gdk-pixbuf
  • rebuild Pillow (which does link against libjpeg):
rm -fr ~/gtk/inst/lib/python2.7/site-packages/Pillow* 
easy_install -U Pillow

And it seems OK now.


For reference, you can find the full list of .dylibs and .sos that use those libraries with command lines like:

cd;clear;reset;find gtk/inst/lib -name "*so" -ls -exec otool -L {} \; | egrep "^gtk/inst|jpeg"

@totaam
Copy link
Collaborator Author

totaam commented Apr 8, 2014

2014-04-08 11:41:39: totaam changed owner from antoine to smo

@totaam
Copy link
Collaborator Author

totaam commented Apr 8, 2014

2014-04-08 11:41:39: totaam commented


Please update your build environment as per above, preferably by merging the new versions in the moduleset as per #533 - then close this ticket.

For win32, this will have to be done as part of #300 (updated and re-scheduled).

@totaam
Copy link
Collaborator Author

totaam commented Apr 15, 2014

2014-04-15 20:37:07: smo commented


I did merge these into the moduleset however I think by adding these to .jhbuildrc-custom might also work

branches["libjpeg"] = "http://softlayer-dal.dl.sourceforge.net/project/libjpeg-turbo/1.3.1/libjpeg-turbo-1.3.1.tar.gz"
branches["libpng"] = "http://softlayer-dal.dl.sourceforge.net/project/libpng/libpng16/1.6.10/libpng-1.6.10.tar.gz"
branches["libtiff"] = "http://download.osgeo.org/libtiff/tiff-4.0.3.tar.gz"

It seem to have compiled those versions on my system when building the rest of gtk so that might be an easier way for osx.

@totaam
Copy link
Collaborator Author

totaam commented May 17, 2014

2014-05-17 10:03:28: totaam commented


The versions in the binary win32 GTK3 builds (see #90) are reasonably up to date, and we should be able to update them more easily, if not build the whole thing from source. The OSX ones are updated as per above, will be tracked in #533.

So I think we can close this.

@totaam totaam closed this as completed May 17, 2014
@totaam
Copy link
Collaborator Author

totaam commented Jun 12, 2014

2014-06-12 06:06:00: totaam commented


Note: as per #263#comment:10, we may want to revive this ticket and use these instructions: GTK+ for Windows to build a more up to date GTK2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant