Bugzilla Bug 69043

pdflib contains an embedded libtiff, and unfortunately a rather heavily
adjusted one. So, large parts of the classic tiff patches do not apply.

Note that this package has no official maintainer.

Sent mail upstream asking for patches

Upstream answer : 

"[...] we are working on these TIFFlib-related issues [...], and will
shortly make available patches and/or recommendations for
workarounds.

Note that we generally release patches or bug fixes only for
the latest maintenance release of a particular major version,
i.e. the recommendation will apply to PDFlib Lite 5.0.4. While
modified patches may work for older maintenance releases such as
5.0.2, we only support the latest maintenance release of a series.

Of course, a solution will also be provided for version 6 (both
PDFlib Lite and commercial products based on PDFlib)."

Upstream update on November 10 :

"PDFlib Lite 5 source code: a patchlevel release 5.0.4p1 will be available
on our Web site ca. next week."

New upstream version available :

----------------------------------
you can find an updated Unix source package for PDFlib Lite 5.0.4p1 at
http://www.pdflib.com/products/pdflib/download-source5.html.

The Changelog entries can be found at
http://www.pdflib.com/products/pdflib/info/PDFlib-5.0.4p1-changes.txt

As announced earlier, the libtiff vulnerability patches will also
be contained in our forthcoming 6.0.1 release, which is expected to
be available for download at the end of November.
------------------------------------

This is semi-public now, since it appears in PDFLib Changelog, but isn't fixed yet in their 6.x versions.

We must find someone to bump to 5.0.4_p1... Package has no clear maintainer.

I think we should bump pdflib to 5.0.4_p1 ASAP and wait for pdflib 6 to be out
(end of November) to issue our GLSA.

Tested simple bump (with "s/_p1/p1" in PV) and it looks ok (it builds and
installs). solar : could you do the bump ?

To test, the following packages depend on PDFLIB (if pdflib use flag set):

app-text/xml2doc
dev-lang/pike
dev-php/mod_php
dev-php/php
dev-php/php-cgi
media-gfx/gnuplot
media-gfx/grace

ChrisWhite agreed to bump this.

In portage, tested with xml2doc on the example xmls with:

xml2doc -oP foo.xml foo.pdf

and viewing them in xpdf.  Only thing that doesn't work is list tag because the latest pdflib doesn't have it implemented, but that's more in the sense of parsing, core functionality is ok.  So then x86 stable.

Argh
6.0.0p1 is NOT fixed (released July, 2004)

Currently only 5.0.4p1 is fixed. So now the upgrade path is much more complex... We can remove 6.0.0p1 very quickly, hope almost nobody got it, and propose an upgrade path to 5.0.4p1 (unlikely) or just wait for 6.0.1 PDFLite to be available and have everyone migrate to that version.

Source accessible through :
http://pdflib.com/products/pdflib/download-source5.html

File in question being :
http://pdflib.com/products/pdflib/download/504src/PDFlib-Lite-5.0.4p1-Unix-src.tar.gz

Note that PDFlib.com just issued 6.0.1 that is fixed as well.
This has no reason for this bug to be kept confidential anymore since PDFlib just released their commercial fix. Opening.

Ok, so bumped to 5.0.4p1 and I'll deal with 6.0.1 later on.  This time re-did
all the tests and re-compiled everything that pdflib depeneded on to ensure
nothing broke.  Nothing broke, x86 stable, I leave this to you.

Arches, please test and mark stable
Target KEYWORDS="x86 ppc sparc ~mips alpha arm hppa amd64 ia64 ppc64 s390"

Tested and marked stable on ppc.

sparc stable.

stable on ppc64

stable on amd64

alpha, we're waiting on you

arm/hppa/ia64/s390 stable

Finally stable on alpha - sorry about the delay.

GLSA 200412-02