New upstream release: FreeImage 3.15.1

Debdiff attached

Builds without any problem in Precise

https://launchpad.net/~cosme/+archive/my-builds?field.series_filter=precise

The attachment "freeimage_3.15.1-0ubuntu1.debdifff" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Cosme

Thanks for taking the time to prepare this update.

Whats the current status of getting this package into Debian? I'd prefer to push a new upstream release that way at this point in the Ubuntu release cycle.

I did take a look at the attached debdiff; however I had issues applying without alot of hacking as the generated upstream tarball contains Windows formatted files so the patch in the debdiff won't apply cleanly. It would be great if that could be tidied up first; maybe using a bzr branch might make that a little easier.

Marking as 'Incomplete' and un-subscribing ubuntu-sponsors pending response on #4

2011/12/2 James Page <email address hidden>:
> Whats the current status of getting this package into Debian? I'd prefer
> to push a new upstream release that way at this point in the Ubuntu
> release cycle.

Debian has a very old FreeImage release (3.10 -> November 19th, 2007)
and patched to use the system libraries instead of his embedded
copies.

I don't have any problem on upload FreeImage to Debian but I can't
spend time in mantain all his patches:

http://patch-tracker.debian.org/package/freeimage/3.10.0-4

Also, I don't think that those changes will be safe.

I prefer keep working with an unpatched release of FreeImage.

> I did take a look at the attached debdiff; however I had issues applying
> without alot of hacking as the generated upstream tarball contains
> Windows formatted files so the patch in the debdiff won't apply cleanly.
> It would be great if that could be tidied up first; maybe using a bzr
> branch might make that a little easier.

I didn't have any issue applying the patch and as I said, 3.15.1
release with this debdiff builds fine in my Launchpad PPA:

https://launchpad.net/~cosme/+archive/my-builds?field.series_filter=precise

But if you want a bzr upload instead of a debdiff then it's done:

https://code.launchpad.net/~cosme/ubuntu/precise/freeimage/freeimage-3.15.1

I upload only the packaging changes. I don't know if I should also
upload the upstream source.

Cosme

I think it is very important that your packaging be reconciled with the packaging currently in Debian. Using embedded copies of libraries as freeimage does is a serious policy violation (http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles) and security issue.

The security team only updates the globally shipped copies of libraries like libjpeg and libpng, relying on packages using them to pick up the update through dynamic linking. Packages containing embedded copies of libraries are not updated in response to security updates, leaving them vulnerable.

Evan, you are right and I know that embedded copies of libraries is a bad idea.

But it seems that upstream like this way and I don't want patch
FreeImage at that level.

If anybody want do that work, go ahead!

Meanwhile we have five Ubuntu stable release with an unsafe FreeImage release.

http://packages.ubuntu.com/search?suite=default&section=all&arch=any&searchon=names&keywords=freeimage

We also could sync Debian patched package, but then we will have to
downgrade Freeimage from 3.13.1 to 3.10 unless anybody wants refresh
all patches to work with latest upstream release.

As far as I know embedded copies in FreeImage "are explicitly intended
to be used in that way". [1]

Also, C&P of Hervé Drolon (FreeImage Project Manager) [2]

"Each FreeImage version is developped, tested and designed to run with a
particular set of third party libraries, each library being configured with
a particular set of options. Each new FreeImage release takes into account
the changes log published by each third party library : this way, the
FreeImage code and it's underlying libraries are always up-to-date
regarding bugs and security issues.
FreeImage provides a very simple API to handle various kinds of bitmaps.
It's provided as a single library (.dll or .so). The fact that it uses a
number of third party libraries is convenient for us, the library
developers, but shouldn't concern the users. We patch the libraries to our
needs, to make optimal use of them."

I prefer use the system libs but I think that should be upstream who
make the change officially
and not us. I do not know if patching FreeImage can break something or
cause unexpected behavior.

But if you want keep thinking that patch FreeImage is a good idea... :-\

[1] http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
[2] http://sourceforge.net/tracker/?func=detail&aid=2925458&group_id=11504&atid=111504

That section of the documentation has to do with the *library* being designed for embedded use, not the *upstream source* designing around embedding a library. It's referring to libraries such as some elements of the GNU toolchain, which are specifically intended to be embedded.

This is a case where Debian (and, by inheritance, Ubuntu) has made a deliberate choice to override the wishes of upstream. The fact that we have multiple Ubuntu releases with unsafe embedded libraries is just proof that embedding libraries is a bad idea.

As a side note, looking at the Debian patch tracker, most of the diff currently in Debian is the result of upgrading the embedded copy of libtiff to resolve outstanding security vulnerabilities, because the Debian maintainer was unable to separate freeimage's use of libtiff internals. Assuming that libtiff in freeimage is up to date, it shouldn't be necessary to carry that diff forward.

Given that, you're just left with the patches to the build system (Makefile.srcs, fipMakefile.srcs, genfipsrclist.sh, and gensrclist.sh) to disable building the embedded libraries and remove them from the include path, and patches to the plugin interface source files (Source/FreeImage/J2KHelper.cpp, Source/FreeImage/PluginEXR.cpp, Source/FreeImage/PluginJ2K.cpp, Source/FreeImage/PluginJP2.cpp, Source/FreeImage/PluginJPEG.cpp, Source/FreeImage/PluginMNG.cpp, Source/FreeImage/PluginPNG.cpp, Source/FreeImage/ZLibInterface.cpp, Source/FreeImageToolkit/JPEGTransform.cpp) which change the #includes to use system libraries instead of the embedded ones (and also to cleanup a SIZEOF macro that doesn't exist)

As I said you are right.

But I don't will patch FreeImage as you want.

Sorry for any inconvenience.

This bug was fixed in the package freeimage - 3.15.1-1

---------------
freeimage (3.15.1-1) unstable; urgency=low

  [ Evan Broder ]
  * QA upload.
  * New upstream release (closes: 649541, LP: #898825, #898845)
    - Refreshed patches.
      + Abuse dh-autoreconf to generate Makefile.srcs and fipMakefile.srcs
        patches at build time
    - Update debian/freeimage-get-orig-source for the new version.
    - Add new build-dep libraw-dev.
    - Update patch to disable embedded libraries to deal with API changes
      in libpng, libmng, and libraw.
    - Make sure we install symlinks for libfreeimageplus.
    - Use (upstream-supported) CFLAGS instead of COMPILERFLAGS.
  * Switch to source format 3.0 (quilt)
  * Switch to dh(1) and debhelper compat 8
  * Add missing misc:Depends.
  * Include the upstream changelog.
  * Update Debian standards version (no other changes needed).

  [ Stefano Rivera ]
  * Dropped README.source.
  * Updated freeimage (3.9.5) fixes CVE-2011-1167, CVE-2011-0192,
    CVE-2010-2595
  * Override lintian's embedded-library error for libtiff. It wasn't
    extricable.

 -- Evan Broder <email address hidden> Tue, 06 Dec 2011 14:31:21 +0200