Bug#995808: --help does not mention required --enable-local-file-access

[Enrico Zini]

Package: wkhtmltopdf
Version: 0.12.6-1
Severity: important

Hello,

Thank you for packaging wkhtmltopdf!

wkhtmltopdf version 0.12.6 blocks by default access to local files (note
the "Warning: Blocked access to file"):

$ wkhtmltopdf test.html test.pdf
Loading page (1/2)
Warning: Blocked access to file
Error: Failed to load about:blank, with network status code 301 and http status code 0 - Protocol "about" is unknown
Printing pages (2/2)
Done
Exit with code 1 due to network error: ProtocolUnknownError

Using --enable-local-file-access makes it work:

$ wkhtmltopdf --enable-local-file-access test.html test.pdf
Loading page (1/2)
Printing pages (2/2)
Done

However, earlier version of wkhtmltopdf did not support
--enable-local-file-access, and using it would cause it to error out
complaining about usage of a non-existing option.

A program calling wkhtmltopdf for rendering needs to figure out when
--enable-local-file-access is needed and when it's harmful, here's an
example use case:

https://github.com/Truelite/python-a38/issues/6

To avoid needing to parse and compare --version output, I had opted to
parse the output of --help: if the option was documented, then it was
needed; if it was not documented, then it wasn't supported.

The version of wkhtmltopdf currently in stable requires
--enable-local-file-access but does not document it (!!)
causing both a conundrum for users who get an error message and no
documentation on the option that would fix it, and for software trying
to figure out the effective CLI interface for manipulating wkhtmltopdf
as a backend tool.


Enrico


-- System Information:
Debian Release: 11.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wkhtmltopdf depends on:
ii libc6 2.31-13
ii libgcc-s1 10.2.1-6
ii libqt5core5a 5.15.2+dfsg-9
ii libqt5gui5 5.15.2+dfsg-9
ii libqt5network5 5.15.2+dfsg-9
ii libqt5printsupport5 5.15.2+dfsg-9
ii libqt5svg5 5.15.2-3
ii libqt5webkit5 5.212.0~alpha4-11
ii libqt5widgets5 5.15.2+dfsg-9
ii libstdc++6 10.2.1-6

Versions of packages wkhtmltopdf recommends:
ii tigervnc-standalone-server [xserver] 1.11.0+dfsg-2
ii xserver-xephyr [xserver] 2:1.20.11-1
ii xserver-xorg [xserver] 1:7.7+22

wkhtmltopdf suggests no packages.

-- no debconf information

[Enrico Zini]

Severity: normal

I found that the option is documented in -H (--extended-help) instead of
--help, and I can successfully use that to figure out what API is
expected by wkhtmltopdf.

I suppose, for such a common use case, that command line option
shouldn't be hidden outside of the normal help, or the error message
should mention the existance of --enable-local-file-access: it really
looks like wkhtmltopdf is unable to render local files!

Depending on sensitivities, the severity and validity of this bug may
vary: I'll leave it up to you to decide whether to keep it open, and
what its severity should be


Enrico

--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>