Haven't seen any announcements yet, but there's a patch
Haven't seen any announcements yet, but there's a patch¹ for xpdf and poppler cvs has the patches applied as well. [1] ftp://ftp.foolabs.com/pub/xpdf/xpdf-3.01pl1.patch
Printing please advise and double check what packages might me affected by this. Handling KDE packages on bug #114433
poppler-0.4.2-r1 was just committed with this fix.
gpdf is bumped to 2.10.0-r2. Targets are: alpha amd64 hppa ia64 mips ppc ppc64 sparc x86
same for xpdf-3.01-r2
Arches please test and mark stable. Target keywords are: poppler-0.4.2-r1.ebuild:KEYWORDS="alpha amd64 ~arm ~hppa ia64 ~mips ppc ppc64 ~sparc x86" xpdf-3.01-r2.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 mips ppc ppc64 s390 sparc x86" gpdf-2.10.0-r2.ebuild:KEYWORDS="alpha amd64 hppa ia64 mips ppc ppc64 sparc x86"
I have marked poppler and xpdf ppc64 stable. I had a runtime problem with gpdf; getting the following error: gpdf: error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or directory Did a little bit of looking but ran out of time. Any other archs seeing this?
sparc stable on xpdf & gpdf. Brent: that's because you probably did an upgrade to a newer gtk+ with the newer cairo, which isn't backwards compatible. revdep-rebuild away and it'll get fixed.
There's a problem with marking poppler-0.4.2-r1 stable, because it depends on cairo >= 0.5, which is not stable anywhere, and is not API compat with older cairo versions. The previous stable version didn't have a dependency on cairo. Of the packages that depend on poppler, evince, kpdf, kdegraphics, and popplerkit depend on newer versions than 0.3.0 (which is stable). abiword-plugins can use that version, but is not stable itself. Maybe we could just remove the old (stable) version of poppler? This is a regression, but the only thing in tree that can use it is not itself stable.
Back to ebuild until we get this sorted out. AFAIK only 0.4.2-r1 is fixed so we either have to mark that version stable or backport the fix for poppler. If the old stable versions of poppler have to go, they have to go.
http://www.idefense.com/application/poi/display?id=342&type=vulnerabilities http://www.idefense.com/application/poi/display?id=343&type=vulnerabilities http://www.idefense.com/application/poi/display?id=344&type=vulnerabilities http://www.idefense.com/application/poi/display?id=345&type=vulnerabilities
Update: I've backported the fix to poppler-0.3.0-r1, and removed the intermediate versions of poppler. Target for poppler-0.3.0-r1 is: alpha amd64 ~arm ~hppa ia64 ~mips ppc ppc64 ~sparc x86 Amd64 is already done.
Back to stable. Printing is pdftohtml affected by this?
poppler-0.3.0-r1 is stable on ppc64. poppler-0.4.2-r1 is back to unstable. ranger didn't run into QA issue with cairo use flag, because it is masked on ppc64. (will check why this is..) I am currently compiling gpdf and its deps. will report back tomorrow, if I get the same error as ranger on his ppc64 machine. (I think I will, because the lib not found has cairo in name and thus won't exist if cairo use flag is masked?)
Yes, pdftohtml is affected. I've revbumped it to pdftohtml-0.36-r4. Target keywords is: amd64 ppc ~ppc-macos ppc64 sparc x86
app-text/{poppler,xpdf,gpdf} app-text/pdftohtml are all stable on x86. Let us know if anything else needs to be stablized.
amd64 done.
ppc64 finaly done
pdftohtml sparc stable.
Arches, please retest xpdf-3.01-r2 since a small glitch happened and the ebuild didn't include the patch (thx to fump for the headsup)
I think cups may be impacted too (as usual... and moreover Fedora has updated tetex) I quickly looked at source cups-1.1.23/pdftops/Stream.cxx and it looks like vulnerability in advisory http://www.idefense.com/application/poi/display?id=342 is present (I did not checked the others concerning Stream.cc) : GBool DCTStream::readBaselineSOF() { int length; int prec; int i; int c; length = read16(); prec = str->getChar(); height = read16(); width = read16(); numComps = str->getChar(); if (prec != 8) { error(getPos(), "Bad DCT precision %d", prec); return gFalse; } for (i = 0; i < numComps; ++i) { compInfo[i].id = str->getChar(); c = str->getChar(); compInfo[i].hSample = (c >> 4) & 0x0f; compInfo[i].vSample = c & 0x0f; compInfo[i].quantTable = str->getChar(); } progressive = gFalse; cups-1.1.23/pdftops/Stream.cxx lines 2883-2905
Printing please advise.
Arches please test xpdf-3.01-r3 and mark stable asap. Sorry for this problem it's all my fault.
xpdf-3.01-r3 stable on amd64. not removing us from CC yet because of comment 20
Stable on hppa, ppc.
Readding x86 sparc ppc64 to mark xpdf as per comment #22
Stable on x86 for xpdf, leaving attached as well for comment #20
stable on ppc64
OK, still missing : alpha ia64 on poppler-0.3.0-r1 alpha arm ia64 mips s390 sparc on xpdf-3.01-r3 alpha ia64 mips ppc on gpdf-2.10.0-r2 Readding ppc for gpdf. pdftohtml is all done. Opening a separate bug for CUPS.
xpdf-3.01-r3 sparc stable.
Stable on ppc.
Done for alpha Sorry for the delay here. Cheers, Ferdy
GLSA 200512-08 arm, ia64, mips, s390 don't forget to mark stable to benifit from the GLSA. Grrr somehow pdftohtml didn't make it to the GLSA. Fixing.
Ok, not so fast. Either we could update the already released GLSA or issue a separate one as we did previously. Opinions?
Maybe I was not clear enough in comment #20, I was suggesting cups AND tetex may be impacted: Extracting tetex-src-3.0/xpdf/xpdf/Stream.cc from tetex-src-3.0.tar.gz, I found the exact same code as in comment #20, so the same vulnerability applies. tetex should be patched too...
jaervosz: I'd issue a separate one. But maybe wait for more (and/or tetex). Open a separate bug and close this one. Olivier: for tetex please open a separate bug (will do it if I have some time left)
Closing this one, opening a separate for pdftohtml
We need to fix GLSA 200512-08 because of wrong poppler versions (should mention 0.3.0-r1, not 0.4.2-r1).
GLSA fixed.
*** Bug 131199 has been marked as a duplicate of this bug. ***
