Bugzilla Bug 114428

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. ***