Bugzilla Bug 117481

Opening separate bugs for cups, poppler, gpdf. 

Handling pdftohtml, tetex, pdff, kword on their respective bugs that are still
open.

kpdf and kword already silently patched in CVS.

CC'ing metalgod for advise. If you commit please only mention the bug # in the
Changelog for now.

metalgod is short on time, CC'ing dang as well.

Are there any fixed patches for this?  None of us are actually devs for
xpdf/poppler/etc...

The patch useb by kpdf and kword is in Portage. I hope there will be an
official upstream patch soon.

Created an attachment (id=76071) [details]
xpdf300_combined.diff

Combined xpdf-3 patch from Ludwig Nussel. Might include some already-fixed
issues so might need some cleanup.

Created an attachment (id=76072) [details]
xpdf202_combined.diff

Combined xpdf-2 patch from Ludwig Nussel, in case it's needed by some tools.

Printing please provide an updated ebuild.

The diff returns a lot of failed hunks when i try to apply it on poppler, do we
have a native poppler patch somewhere?

poppler is bumped to poppler-0.4.3-r4 with this fix.  Xpdf is not yet done.

xpdf-3.01-r5 is bumped with these fixes.

Arches please test and mark stable.

stable on ppc64

Handling stable marking of Xpdf on bug #117495, please see that bug for details
about stable marking.

app-text/xpdf-3.01-r5 marked stable on hppa.

sparc done, i think :)

ppc stable

amd64 stablized as mentioned in bug 117495

as the maintainer for pdftohtml, could I please be CC when these holes crop up?
I'm not a member of the printing herd.

Related to Xpdf security holes, I was just reviewing pdftohtml's existing
patches vs. poppler, and I noticed that poppler seems to be missing the fixes
from xpdf2-underflow.patch. Could the security team or the poppler maintainers
please take a look at it?

Seeing how poppler and pdftohtml are diverging, I'd like to know of any
functionality differences in the pdftohtml provided by the pdftohtml from each
of the poppler and pdftohtml codebases. The only one I see at a glance is the
-nodrm stuff in poppler. (FYI even the poppler pdftohtml claims to be
pdftohtml-0.36, might want to change that ;-).

x86 done

Robbat, see bug #115789 for the pdftohtml bug.

Printing please advise on missing patch.

jaervosz: Yes I see #115789. We're trying to figure if pdftohtml should just be
dropped in favour of poppler, as they do seem to be reasonably close in terms
of functionality.

And stable marking can continue:-)

[00:15:06] <@taviso> jaervosz: looks like poppler doesnt need the underflow
patch
[00:15:12] <@taviso> so i would say, safe

Bahh sorry for the bug spam. Stable marking is on bug #117495

pdftohtml is now in p.mask, and will be removed early next week (keeping it
around for a few days in case problems crop up).

I've changed all deps in the tree (sys-cluster/charm and
app-zope/portaltransforms for those keeping track) to point to poppler instead.

The dep blocker in poppler of "!app-text/poppler" remains, as a way to force
users to uninstall pdftohtml and move to poppler instead.

We should probably push this info to the GWN team.

Mail send to GWN a few days ago.

GLSA 200601-17

And now actually closing.