Package Details: libpdfium-nojs 4103.r0.daabea6ba6-1

Git Clone URL: (read-only, click to copy)
Package Base: libpdfium-nojs
Description: Open-source PDF rendering engine.
Upstream URL:
Keywords: pdf pdfium
Licenses: BSD
Conflicts: libpdfium-bin
Provides: libpdfium
Submitter: selmf
Maintainer: selmf
Last Packager: selmf
Votes: 12
Popularity: 2.39
First Submitted: 2017-07-30 18:14
Last Updated: 2020-05-20 13:18

Latest Comments

1 2 3 Next › Last »

selmf commented on 2020-05-27 15:41

@WonderCaT_007: Thanks for reporting. I don't think you need to be concerned. The files in question are part of Pdfium's test corpus and they probably are present to test if Pdfium is vulnerable to the exploits contained.

None of these files are being installed or run by the package and as the package comes with javascript support disabled many exploits won't work anyway.

While I still wouldn't recommend opening these with a pdf reader I don't think they contain malicious code (probably the exploit only, no payload). But that is just my assumption, upstream can probably tell you more.

WonderCaT_007 commented on 2020-05-27 15:27

The package was creation was successful. However, I did a clamav scan of the build directory and it detected two files as malicious or contains some kind of exploit code. To confirm the detection, I just checked those files with online virustotal, and one of them were detected by 18 anti virus engines. Should we be concerned?

Here are the files: libpdfium-nojs/src/pdfium/testing/resources/js.pdf: Pdf.Dropper.Agent-7158272-0 FOUND < Detected by 18 av engines in Virustotal

libpdfium-nojs/src/pdfium/testing/resources/pixel/bug_867501.pdf: Pdf.Exploit.TALOS_2018_0639-6680787-0 FOUND < Detected just by clamav

paarthri commented on 2020-05-25 19:49

Yes, installing pkgconf solved the problem for me.

selmf commented on 2020-05-24 23:13

@paarthi: Works for me. Pkgconfig is probably missing or defect on your system, so you should check if it is present and working correctly.

paarthri commented on 2020-05-24 22:41

This package is not building on my computer.

ERROR at //build/config/linux/pkg_config.gni:103:17: Script returned non-zero exit code.
    pkgresult = exec_script(pkg_config_script, args, "value")
Current dir: /home/paarth/.cache/yay/libpdfium-nojs/src/pdfium/out/Release/
Command: /usr/bin/python2 /home/paarth/.cache/yay/libpdfium-nojs/src/pdfium/build/config/linux/ gio-2.0
Returned 1.

Could not run pkg-config.

See //build/linux/ whence it was called.
  pkg_config("gio_config") {
See //build/config/freetype/ which caused the file to be included.
    public_configs = [ "//build/linux:freetype_from_pkgconfig" ]
==> ERROR: A failure occurred in build().
Error making: libpdfium-nojs

selmf commented on 2020-05-16 08:51

Hi PedroHLC,

I am well aware that this package is some kind of chimera between a VCS and a stable package. If I could simply use fragment to clamp to a specific release tag I would already have done so or I wouldn't use git to get the source at all.

The problem here is that upstream does not use tags at all. Pdfium releases as defined by Chromium are branches and these branches are moving targets as they occasionly do get security and other fixes backported.

With upstream being a moving target I opted for the current mechanism to create a package version that is able to keep track of the backported fixes (this is only possible by comparing the master and stable branch) and delivering the current stable version.

I'm open to discussion for clamping this package to a known stable branch instead of dynamically checking which branch is the latest stable, but I can't do proper release management without keeping track of the backport commits.

I'm also open to resubmitting the current version of this package as something like libpdfium-nojs-stable-git.

PedroHLC commented on 2020-05-14 12:32

Hi selmf.

Please, follow the ArchWiki VCS's guideline, resubmitting. this package as libpdfium-nojs-git.

And in this one use chromium stable releases tags and use fragment ( to lock specifically to that tag.

This way is clearer for the end user what kind of package he installed, it's easy to keep dependencies synced, and AUR helpers understand they need to check pkgver() to find updates...

pad commented on 2020-05-14 08:14

PKGBUILD need a update of pkgver to 4044.r0.04bb1f2f03-1 ?

selmf commented on 2019-10-08 05:28

@steinbuch: Not sure what your issue is, I just tested it and the build ran fine on my system.

Using depot_tools is something I intentionally avoid doing for this package. It pulls lots of unneeded source dependencies and my goal is to unbundle all third party stuff and slim down the build as much as possible.

As this is a semi-git-package that tracks Chromium's stable branch to decide which checkout of the pdfium code to use breakage can happen when Chromium releases a new version. If this occurs you can just send me an out of date notification ;)

steinbuch commented on 2019-10-07 23:34

It no longer builds. (using depot_tools) could be an alternative.