Opened 18 months ago

Closed 9 months ago

Last modified 9 months ago

#54808 closed update (fixed)

poppler @0.57.0: update to 0.65.0

Reported by: l2dy (Zero King) Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version:
Keywords: security Cc: pmetzger (Perry E. Metzger), drkp (Dan Ports), NicosPavlov, dliessi (Davide Liessi), mojca (Mojca Miklavec)
Port: poppler

Description


Attachments (1)

patch-Portfile.diff (972 bytes) - added by NicosPavlov 9 months ago.
Patch to deactivate subport poppler-qt4-mac

Download all attachments as: .zip

Change History (50)

comment:1 Changed 17 months ago by l2dy (Zero King)

Summary: poppler @0.57.0: update to 0.59.0poppler @0.57.0: update to 0.60.1

comment:2 Changed 17 months ago by l2dy (Zero King)

Summary: poppler @0.57.0: update to 0.60.1poppler @0.57.0: update to 0.61.0

comment:3 Changed 16 months ago by kprussing (Keith)

Just as a note, the dependency for lbzip2 is missing for the 0.57.0 port. I just tried reinstalling and the log file said it could not find it. Installing lbzip2 got poppler to install for me. Since the migration to a newer version is under way, I didn't see the use in opening a different ticket for this.

comment:4 in reply to:  3 Changed 16 months ago by mf2k (Frank Schima)

Replying to kprussing:

Since the migration to a newer version is under way, I didn't see the use in opening a different ticket for this.

If you want the issue fixed, you should file a new ticket. It will likely get ignored as part of this ticket which is about updating poppler.

comment:5 Changed 15 months ago by l2dy (Zero King)

Summary: poppler @0.57.0: update to 0.61.0poppler @0.57.0: update to 0.62.0

comment:6 Changed 14 months ago by pmetzger (Perry E. Metzger)

Cc: pmetzger added

comment:7 Changed 14 months ago by pmetzger (Perry E. Metzger)

There are security vulnerabilities associated with the version of poppler we are installing.

Last edited 14 months ago by pmetzger (Perry E. Metzger) (previous) (diff)

comment:8 Changed 10 months ago by drkp (Dan Ports)

Cc: drkp added

comment:9 Changed 10 months ago by drkp (Dan Ports)

Any update? The next version of texlive appears to require a newer version of poppler that what we have.

comment:10 Changed 10 months ago by pmetzger (Perry E. Metzger)

drkp: My suggestion: submit a pull request on GitHub for an update and it will get relatively rapid consideration.

comment:11 Changed 10 months ago by l2dy (Zero King)

Summary: poppler @0.57.0: update to 0.62.0poppler @0.57.0: update to 0.64.0

From the current Portfile:

# version 0.58.0 includes C++11 extensions that break
# build of a number of dependents (inkscape, texlive-bin, etc)
# hold off on update until this is sorted out

I'm not sure if this has been sorted out now.

comment:12 Changed 10 months ago by pmetzger (Perry E. Metzger)

l2dy: There's one way to figure that out I suppose, which is to check them. Regardless, since this is a security issue, I don't think we can hold off, we need to push it forward.

comment:13 Changed 10 months ago by drkp (Dan Ports)

Cc: NicosPavlov dliessi mojca added

Looking into this a bit more: the latest version of poppler removed support for qt4, which would mean we'd have to remove the poppler-qt4-mac port. It has dependents:

> port echo depends:poppler-qt4-mac
kfilemetadata                   
nepomuk-core                                                                   
okular                                                                         
py27-poppler-qt4                
py34-poppler-qt4                
py35-poppler-qt4                
py36-poppler-qt4                
texworks

I've cc'd the maintainers. Is this something we can work around somehow? It sounds like some of these aren't things we could just upgrade to poppler-qt5-mac...

comment:14 Changed 10 months ago by mojca (Mojca Miklavec)

TeXworks works with Qt5.

comment:15 Changed 10 months ago by pmetzger (Perry E. Metzger)

Okular is actively maintained, so I suspect it probably can handle qt5.

I will mention again, the old poppler has security bugs.

comment:16 Changed 10 months ago by raimue (Rainer Müller)

Keywords: security added

comment:17 Changed 10 months ago by dliessi (Davide Liessi)

The current port for Frescobaldi depends on py-poppler-qt4. Version 3 of Frescobaldi depends on py-poppler-qt5 but has some bugs on Mac, so I haven't updated it yet.

Updating to version 3 means that essentially one menu stops working and that Frescobaldi is not available prior to Lion anymore (due to Qt 5).

The bugs will need to be sorted out eventually, so they are not a valid reason to avoid upgrading Poppler. I would really like to keep Frescobaldi working on Snow Leopard, which means having a working Qt 5 on Snow Leopard: I could help with testing but I lack the expertise required to resurrect Qt 5.3 on Snow Leopard.

comment:18 Changed 10 months ago by drkp (Dan Ports)

I've got a patch to upgrade to poppler 0.64.0; let me see which of the dependents break.

comment:19 Changed 10 months ago by NicosPavlov

Okular, nepomuk-core and kfilemetadata will most likely break. They are all based on kde4, which itself relies on qt4. There are more recent version, but they require kf5/qt5, which is not provided by Macports.

comment:20 Changed 10 months ago by pmetzger (Perry E. Metzger)

Is kf5 hard to provide? I'm in favor of just breaking Okular etc. for now given that this is a security issue.

comment:21 Changed 10 months ago by NicosPavlov

Is kf5 hard to provide?

Yes, I think it is. It would require the creation of a fairly large amount of ports (>10), with quite some problems to be expected downhill, as the code is not really tested on Mac for what I know. There have been attempts, but nothing mature or integrable enough to be committed. I do not expect KF5 to be provided by Macports any time soon.

Which versions suffer from the vulnerabilities? I saw that 0.61 still has the qt4 frontend, so it would be possible to upgrade to this without adverse consequences for ports. It could also be an idea to make a poppler-qt4 port for older code and a newer poppler one.

Also, the port mentions

# version 0.58.0 includes C++11 extensions that break
# build of a number of dependents (inkscape, texlive-bin, etc)
# hold off on update until this is sorted out

Is this resolved? Breaking okular is one thing, but breaking several large ports is another to me.

comment:22 in reply to:  21 Changed 10 months ago by drkp (Dan Ports)

Replying to NicosPavlov:

Also, the port mentions

# version 0.58.0 includes C++11 extensions that break
# build of a number of dependents (inkscape, texlive-bin, etc)
# hold off on update until this is sorted out

Is this resolved? Breaking okular is one thing, but breaking several large ports is another to me.

I'm checking this out now -- I have a VM rebuilding the dependents to see what breaks.

So far the only issues I've found are texlive-bin (which is surprising since the 2018 version normally builds with its own copy of poppler 0.63 -- still need to check it out) and inkscape.

comment:23 Changed 10 months ago by l2dy (Zero King)

FWIW, Poppler through 0.64.0 is affected by CVE-2017-18267, fixed in https://cgit.freedesktop.org/poppler/poppler/commit/?id=60b4fe65bc9dc9b82bbadf0be2e3781be796a13d.

comment:24 Changed 10 months ago by mojca (Mojca Miklavec)

texlive-bin should not break. If there's something wrong, I'm sure upstream can fix it quickly. Note also that there are a number of upstream patches for TeX Live 2018 in a separate branch.

comment:25 in reply to:  20 Changed 10 months ago by raimue (Rainer Müller)

Replying to pmetzger:

Is kf5 hard to provide?

See also wiki:KDEProblems#Qt5andKF5 which discusses issues with introducing KF5.

comment:26 in reply to:  21 Changed 10 months ago by drkp (Dan Ports)

Replying to NicosPavlov:

Which versions suffer from the vulnerabilities? I saw that 0.61 still has the qt4 frontend, so it would be possible to upgrade to this without adverse consequences for ports. It could also be an idea to make a poppler-qt4 port for older code and a newer poppler one.

I actually gave this a try -- building the qt4 bindings from 0.61 with poppler at 0.64. It didn't work, which didn't really come as a surprise.

This isn't the first security issue poppler has had, and I'm sure it won't be the last, so I'm not too thrilled with any answer that requires us pinning the port to an older version.

comment:27 Changed 10 months ago by l2dy (Zero King)

Summary: poppler @0.57.0: update to 0.64.0poppler @0.57.0: update to 0.65.0

comment:28 Changed 9 months ago by drkp (Dan Ports)

To move this forward a little, here is a PR for a update to 0.65.0: https://github.com/macports/macports-ports/pull/1975

I've added notes about the dependents that I have looked into fixing (texlive-bin + inkscape); there are two others (vips and pdfhtmlex) that I haven't yet. However, I still don't know what to do about the ports that need qt4 bindings and can't easily be updated to qt5.

comment:29 Changed 9 months ago by pmetzger (Perry E. Metzger)

At the risk of drawing ire, I think if something is broken by a badly needed security fix, we probably accept that it broke for now and try to backfill later if we can.

comment:30 Changed 9 months ago by pmetzger (Perry E. Metzger)

One other possibility: produce a new port that installs the old poppler to a distinct set of names so it can be installed at the same time. But this seems bad because the old one is known to be a security problem.

comment:31 Changed 9 months ago by NicosPavlov

While I surely don't like the idea of breaking ports, the fact is that KDE4 is not maintained anymore, so that having parts of it breaking because of this lack of maintenance is just waiting to happen. Fixing a security issue seems like a good reason to do that.

I expect okular to not be recoverable, as it heavily depends on poppler to render PDF files. Possibly the others (nepomuk-core and kfilemetadata) can still build with reduced capabilities, I'll look into that.

comment:32 Changed 9 months ago by kencu (Ken)

the patch to fix the (rather trivial) security issue is extremely minor <https://cgit.freedesktop.org/poppler/poppler/commit/?id=60b4fe65bc9dc9b82bbadf0be2e3781be796a13d>.

It would be nice to keep a version of poppler around that supports qt4, if we can.

Last edited 9 months ago by kencu (Ken) (previous) (diff)

comment:33 Changed 9 months ago by pmetzger (Perry E. Metzger)

kencu: if you want, why don't you construct a version of poppler that doesn't conflict with the normal one and which can keep the qt4 stuff going? And for the rest, we should update poppler and unblock things like updating TeX.

comment:34 Changed 9 months ago by kencu (Ken)

In case it is decided to fix this bug and take some time to sort out a poppler plan, here's a PR <https://github.com/macports/macports-ports/pull/1993> that backports this fix into our current poppler. This will be needed at any rate for any plan to continue supporting breakage if poppler is pushed up to 0.65.0.

comment:35 in reply to:  32 Changed 9 months ago by l2dy (Zero King)

Replying to kencu:

the patch to fix the (rather trivial) security issue is extremely minor <https://cgit.freedesktop.org/poppler/poppler/commit/?id=60b4fe65bc9dc9b82bbadf0be2e3781be796a13d>.

But there are many more CVEs like CVE-2017-14517, CVE-2017-14518, CVE-2017-14519, CVE-2017-14520, CVE-2017-14975, CVE-2017-14976, CVE-2017-14977, CVE-2017-15565, CVE-2017-14929, CVE-2017-1000456.

comment:36 Changed 9 months ago by kencu (Ken)

Ah, thanks for filling in.

comment:37 Changed 9 months ago by pmetzger (Perry E. Metzger)

In the end, I think biting the bullet and accepting the breakage is the only choice. It isn't what we would prefer, but so much of the world isn't what we would prefer.

comment:38 Changed 9 months ago by NicosPavlov

Just in case, I can confirm that kfilemetadata and nepomuk-core have only an optional dependency on poppler, so that they could still build even without qt4 support.

comment:39 Changed 9 months ago by pmetzger (Perry E. Metzger)

As described in the current pull request, I am now proposing to merge the new Poppler about a day from now. At that point, we'll have a bunch of broken ports that will need to be fixed quickly or documented as broken.

comment:40 Changed 9 months ago by l2dy (Zero King)

Below is from openSUSE-SU-2018:1721-1. In case someone wants to backport patches.

  • CVE-2017-14517: Prevent NULL Pointer dereference in the XRef::parseEntry() function via a crafted PDF document.
  • CVE-2017-9865: Fixed a stack-based buffer overflow vulnerability in GfxState.cc that would have allowed attackers to facilitate a denial-of-service attack via specially crafted PDF documents.
  • CVE-2017-14518: Remedy a floating point exception in isImageInterpolationRequired() that could have been exploited using a specially crafted PDF document.
  • CVE-2017-14520: Remedy a floating point exception in Splash::scaleImageYuXd() that could have been exploited using a specially crafted PDF document.
  • CVE-2017-14617: Fixed a floating point exception in Stream.cc, which may lead to a potential attack when handling malicious PDF files.
  • CVE-2017-14928: Fixed a NULL Pointer dereference in AnnotRichMedia::Configuration::Configuration() in Annot.cc, which may lead to a potential attack when handling malicious PDF files.
  • CVE-2017-14975: Fixed a NULL pointer dereference vulnerability, that existed because a data structure in FoFiType1C.cc was not initialized, which allowed an attacker to launch a denial of service attack.
  • CVE-2017-14976: Fixed a heap-based buffer over-read vulnerability in FoFiType1C.cc that occurred when an out-of-bounds font dictionary index was encountered, which allowed an attacker to launch a denial of service attack.
  • CVE-2017-14977: Fixed a NULL pointer dereference vulnerability in the FoFiTrueType::getCFFBlock() function in FoFiTrueType.cc that occurred due to lack of validation of a table pointer, which allows an attacker to launch a denial of service attack.
  • CVE-2017-15565: Prevent NULL Pointer dereference in the GfxImageColorMap::getGrayLine() function via a crafted PDF document.
  • CVE-2017-1000456: Validate boundaries in TextPool::addWord to prevent overflows in subsequent calculations.

comment:41 Changed 9 months ago by pmetzger (Perry E. Metzger)

I think backporting patches indefinitely is a fool's errand. :(

comment:42 Changed 9 months ago by kencu (Ken)

yeah. at first I thought there was only the one.

Blast it in, let the fallout happen, and we'll support what we can.

I already have the old version pegged in repos for older systems.

comment:43 Changed 9 months ago by drkp (Dan Ports)

Resolution: fixed
Status: newclosed

comment:44 Changed 9 months ago by kencu (Ken)

I have a put together a version of poppler 0.61.1, which is the last version that supported the qt4 interfaces. It's actually only a couple of months old, so not very out of date. It co-installs with poppler 0.65.0, and seems to stay out of the way of it.

With that, and a bit of tweaking to the poppler-qt4.pc file, I can install py-qt4 bindings, and then install frescobaldi on 10.6.8 still. It appears to work normally, and perhaps the other py-qt4 things might work as well.

It's still a bit of a WIP as I just finished it, but it works. I'll polish it up a bit, and then perhaps anyone interested can take a look and see where I've made poor assumptions and help me fix it to release status.

comment:45 Changed 9 months ago by pmetzger (Perry E. Metzger)

@kencu, is a patch that makes the py-qt4 stuff use the new API very hard? That would be a better choice, IMHO?

comment:46 Changed 9 months ago by NicosPavlov

The upgrade seems fine for me, and after testing, it appears that none of my ports (kfilemetadata, nepomuk-core and okular) are broken, but only have reduced functionality.

There is one issue though that I am waiting to solve before upgrading them. Simply suppressing poppler-qt4-mac subport is not the proper way to do it in my opinion, as it leaves the port hanging in the registry, while not existing anymore. I attach a patch leaving the subport as obsolete, and using the deactivate hack to ensure that the subport is properly removed.

Changed 9 months ago by NicosPavlov

Attachment: patch-Portfile.diff added

Patch to deactivate subport poppler-qt4-mac

comment:47 Changed 9 months ago by kencu (Ken)

Well, rather than obsolete it, why not use what I just built? Then we can keep it. <https://github.com/kencu/myports/tree/master/graphics/poppler-qt4-mac> . It's nearly done.

Dan tried putting qt4 into poppler 0.65.0 above, and apparently it didn't work.

I think of security issues in the way of opening your system up to outside control, or allowing someone to bounce email off your system to an unsuspecting server.

The mentioned security issues with poppler are mostly just identifying programming bugs that get into an endless loop. That's not a worry to me.

comment:48 Changed 9 months ago by pmetzger (Perry E. Metzger)

Well, rather than obsolete it, why not use what I just built? Then we can keep it.

Because it's not maintainable going forward. Poppler gets lots of security bugs, and the old version will inevitably become more and more of a pain to maintain. And no, you can take control of someone's machine with some of these by giving someone a file to view in email.

comment:49 Changed 9 months ago by kencu (Ken)

I guess I didn't realize that there were so many MacPorts users out there who had configured frescobaldi as their email viewer for PDF files.

Anyway, joking aside, you seem determined to kill this, despite your comment above. And to be honest, what do I care? I have it all working fine on my system, and I dare the KGB to come after me.

Note: See TracTickets for help on using tickets.