I'd take care of it.

Same here and more precisely I downgraded to version 0.12.0-3.5 of libpoppler5 and it worked.

Done.

I found the reason, this security update change some header's of xpdf-poppler used, when I build the xpdf-poppler with the latest libpoppler-devel,  it works fine.

 You can test it from my build service for test.

https://api.opensuse.org/build/home:BinLi:branches:openSUSE:11.2/standard/i586/xpdf-poppler/xpdf-poppler-3.02-7.1.i586.rpm
https://api.opensuse.org/build/home:BinLi:branches:openSUSE:11.2/standard/x86_64/xpdf-poppler/xpdf-poppler-3.02-7.1.x86_64.rpm

Thomas,

 When update the fix from Bug #507102 - VUL-0: poppler: multiple integer overflows in "pdftops" filter (CVE-2009-0791), the xpdf-poppler also need to be updated.
 How do let it work?

When we (sec-team) know the list of affected packages we just would create patchinfos for them in SWAMP. xpdf-poppler depends on poppler which means it will be rebuild automatically.

Should we release xpdf-poppler?

Yes, we need release the xpdf-poppler.

And from Bug 569318 - libpoppler4 too old for KDE Okular in KDE SC 4.4, maybe we need also release the kdegraphics4 which depends the libpoppler-devel in openSUSE 11.1, currently I'm not 11.1 in hand, so I need to install a new to make sure about it.

 So do we fixed together? If not, release this first.

Thanks!

so the safeint patch broke binary compatibility which is not surprising and bad for a library in released distros. How did upstream fix the problems?

Ludwig,

 Gabriel already submit the safeint patch into upstream from https://bugs.freedesktop.org/show_bug.cgi?id=26047 .
 And the upstream refuse to accept it.

Well, what do you expect if you submit a patch for an old version? That was not my question anyways. Since upstream doesn't use the safeint patch how does their fix look like?

Ludwig,

 It don't need a patch for just rebuild the xpdf-poppler which depends the new libpoppler-devel.
 
 The upstream thought this CVE bug is a making money bug, :), so not care of it very much.

The problem is that we should not change the ABI on our library packages.

there is more than xpdf-poppler linking against poppler for instance, we have sev eral others (evince, kde4-okular, cups) ... Also the customer can have their own applications linking against poppler and we might have broken them without chance for us to fix it.

And some other application doesn't build with the sec update, for example:

libextractor -> http://www.gnu.org/software/libextractor/

config.log:

configure:19382: checking poppler/goo/gmem.h usability
configure:19382: gcc -c -fno-strict-aliasing -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables  conftest.c >&5
In file included from conftest.c:108:
/usr/include/poppler/goo/gmem.h:47: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'SafeInt'
/usr/include/poppler/goo/gmem.h:126: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'operator'

Detlef

Detlef,

 I think you should use g++ instead of gcc for your issue.

*** Bug 571361 has been marked as a duplicate of this bug. ***

*** Bug 571293 has been marked as a duplicate of this bug. ***

->Security team.

cc dirk, pgajdos

I'd vote for reverting the update and fix it in a better way

we need to at least revert the SafeInt patch.

the g*alloc binary incompatible change is not acceptable.


(and also these g*alloc functions are C functions, not C++, so we cannot use classes)

(In reply to comment #9)
> my question anyways. Since upstream doesn't use the safeint patch how does
> their fix look like?

The problem is, that our security team wanted better fix than upstream have :-). That is why the xpdf-safe-int.patch has arisen, why is so huge and why I was convinced from the beginning this patch is not upstreamable. I suggest read bug 502974 for more informations. 

I have talked with sbrabec and he suggested to (carefully) consider version update for poppler, if there is no ABI change and addresses said security problem sufficiently. 

Alternatively (for older distributions for example), original small patch from upstream -- bug 502061, comment 2 could be backported.

I have found a method to make the safeint patch more "safe" for this reasons,
by hjust exporting the extern "C" version with normal ints and  C++ variants with SafeInt.

I am attaching the new patch and the diff between the two.

Created attachment 337644 [details]
new  safeint patch

Created attachment 337646 [details]
interdiff

incremental patch to the one we released.

(both for 11.2)

That said ...

Unless we can bring this patch upstream I would say that we remove it from our packages again and proceed with either smaller patches or a version upgrade.

for 11.2 a version upgrade might be feasible (major version is still "5"), for older products not so easy.

We would only revert the safeint patch from poppler (it can stay in the xpdfs and other non libraries).

so to do:
- bili: remove safe int patch from popplers and get them submitted, all opensuse and sle branches :/ so we can proceed with unbreaking the buildsystem and our customers.


- bili: for 11.2 can you do test builds of a version update to 0.12.3?


- did we miss any security fixes?

*** Bug 573867 has been marked as a duplicate of this bug. ***

I do it now, submit it later, :)

Marcus,

 Do we need a swampid for it? I prepare resubmit it without safe-int patch.

The SWAMPID for this issue is 30658.
Please submit the patch and patchinfo file using this ID.
(https://swamp.suse.de/webswamp/wf/30658)

yes.

Done for 11.1 and sle11.

 31311  State:new     Creator:BinLi        When:2010-02-02T11:57:47
        submit:       home:BinLi:branches:openSUSE:11.1:Update/poppler    ->  openSUSE:11.1:Update   
        Comment: 'Comment poppler-CVE-2009-0791-safe-int.patch(bnc#570183,swampid#30658)'

  4284  State:new     Creator:BinLi        When:2010-02-02T12:01:44
        submit:       home:BinLi:branches:SUSE:SLE-11:Update/poppler      ->  SUSE:SLE-11:Update     
        Comment: 'Comment poppler-safe-int.patch(bnc#570183,swampid#30658)'

also 11.2 please, this is where we had the original reports

Marcus,

 Done for 11.2, and I upgrade to 0.12.3, and delete some patches which were in upstream.

 31346  State:new     Creator:BinLi        When:2010-02-02T16:57:07
        submit:       home:BinLi:branches:openSUSE:11.2:Update:Test/poppler  ->  openSUSE:11.2:Update:Test   
        Comment: 'Update to version 0.12.3(bnc#507183,swampid#30658)'

-> Security team.

Thanks!

It looks like the update has dependency problems with okular on openSUSE 11.2 - see bug 579370 for details.

reassigning to Bin Li.

I had discussed this with Dirk and we reviewed this case ...


We will be releasing an updated okular too, in the KDE 4.3.5 update.

So the release of the poppler 11.2 update will just wait until ther KDE 4.3.5 
upgrade.

So nothing to do but wait right now.

Are you saying that opensuse 11.2 users will fix the problem only if they will upgrade to kde 4.3.5?

the poppler update will update "okular" if present on the system. it does not require the kde 4.3.5 update

The answers here are very dense and not very understandable for affected users.

So "the poppler update will update "okular"" means that the update has not rolled out yet? Any estimation when it will happen? This list talks about the update for over two weeks now, with xpdf in an unuable state since over a month...

The update has not been rolled out yet.

I am sorry that its taking so long, but fixing base libraries like poppler is not easy nor fun, especially if you do serveral tries.

But why should opensuse 11.2 users wait the kde 4.3.5 upgrade if poppler patch is independent?

we decided to do a version upgrade for poppler in 11.2.

however okular (KDE PDF / Document viewer) has a requires: poppler-qt == %version
on the poppler version it was built on, so the two are connected to each other.
thats hte reason we need to do this in sync.

Update released for: libpoppler-devel, libpoppler-doc, libpoppler-glib-devel, libpoppler-glib4, libpoppler-glib4-debuginfo, libpoppler-qt2, libpoppler-qt2-debuginfo, libpoppler-qt3-devel, libpoppler-qt4-3, libpoppler-qt4-3-debuginfo, libpoppler-qt4-devel, libpoppler5, libpoppler5-debuginfo, poppler, poppler-debugsource, poppler-tools, poppler-tools-debuginfo
Products:
openSUSE 11.2 (debug, i586, x86_64)

donereelased

I updated but xpdf looks broken: it does not start any more.
This is its output:
xpdf: symbol lookup error: xpdf: undefined symbol: _ZN12GlobalParams23setForceNoFTAutoHintingEPc

Does xpdf-poppler need an update?

My xpdf-poppler is xpdf-poppler-3.02-4.3.i586

xpdf-poppler update released

Works for me.

For me too.

Do I have to do something other than a normal on-line update?  I don't
get a segmentation violation any longer, but I do get this failure:
/usr/bin/xpdf: symbol lookup error: /usr/bin/xpdf: undefined symbol: _ZN15SplashOutputDev18setFreeTypeHintingEi

I just updated.

Update released for: libpoppler4
Products:
openSUSE 11.1 (i586, ppc, x86_64)

Update released for: libpoppler-devel, libpoppler-doc, libpoppler-glib-devel, libpoppler-glib4, libpoppler-qt2, libpoppler-qt3-devel, libpoppler-qt4-3, libpoppler-qt4-devel, libpoppler4, poppler, poppler-debuginfo, poppler-debugsource, poppler-tools
Products:
SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11 (i386, x86_64)
SLE-SDK 11 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)

This is an autogenerated message for OBS integration:
This bug (570183) was mentioned in
https://build.opensuse.org/request/show/31311 11.1 / poppler