poppler @0.57.0: update to 0.65.0

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

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

[pmetzger (Perry E. Metzger)]

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

[drkp (Dan Ports)]

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

[pmetzger (Perry E. Metzger)]

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

[l2dy (Zero King)]

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.

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

[drkp (Dan Ports)]

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

[mojca (Mojca Miklavec)]

TeXworks works with Qt5.

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

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

[drkp (Dan Ports)]

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

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

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

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

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

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

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

[raimue (Rainer Müller)]

Replying to pmetzger:

Is kf5 hard to provide?

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

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

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

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

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

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

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

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

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

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

[kencu (Ken)]

Ah, thanks for filling in.

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

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

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

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

[pmetzger (Perry E. Metzger)]

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

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

[drkp (Dan Ports)]

Updated to 0.65.0 in [d29b807e67d1bc7d696abf7b4bb58fe2049df24c/macports-ports]

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

[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?

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

[NicosPavlov]

Patch to deactivate subport poppler-qt4-mac

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

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

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