Bug#606885: xpdf: no longer asks for password in dialog window
> Nowadays, when the user attempts to view a password-protected PDF
> file, no dialog window is shown
In the original Xpdf, StandardSecurityHandler::checkEncryption calls
back into PDFCore::getPassword if the password's wrong. This code has
been removed from Poppler, so xpdf's implementation of getPassword
wasn't being called.
I've fixed it in xpopple with the following patch, which makes it prompt
for the password up to three times if opening a file fails with
errEncrypted:
--- xpdf/PDFCore.cc
+++ xpdf/PDFCore.cc
@@ -139,11 +139,26 @@ PDFCore::~PDFCore() {
int PDFCore::loadFile(QCONST GooString *fileName, QCONST GooString
*ownerPassword,
QCONST GooString *userPassword) {
int err;
+ std::unique_ptr promptPassword;
+
+ for (int i = 0; i < 3; ++i) {
+setBusyCursor(true);
+err = loadFile2(new PDFDoc(fileName->copy(), ownerPassword, userPassword,
+ this));
+setBusyCursor(false);
+
+if (err != errEncrypted) {
+ break;
+}
+
+// Password not supplied or not correct -- prompt for it
+promptPassword.reset(getPassword());
+if (!promptPassword) {
+ break;
+}
+ownerPassword = userPassword = promptPassword.get();
+ }
- setBusyCursor(true);
- err = loadFile2(new PDFDoc(fileName->copy(), ownerPassword, userPassword,
-this));
- setBusyCursor(false);
return err;
}
(You may also need to add #include to get the definition of
unique_ptr if it's not already in your version.)
Thanks,
--
Adam Sampson
Bug#606885: xpdf: no longer asks for password in dialog window
Hi Florian,
> I wasn't sure how to triage this bug without a password-protected
> PDF file handy, but it turns out Libreoffice can create those.
I recently used pdftk to create a password-protected PDF file.
Something like
$ pdftk plain.pdf cat 1-end output protected.pdf user_pw secret
should work from the command line.
> xpdf will abort with an error ("Command Line Error: Incorrect password")
> unless the correct password is supplied on the command line. This is
> probably not very useful in cases where xpdf is not started from the
> command line (web browser, graphical file manager, ...).
The problem also appears with the poppler-utils, e.g.:
$ pdfinfo protected.pdf
Command Line Error: Incorrect password
I suspect this to be one of the many bugs that arise due to
inconsistency between xpdf and poppler (libpoppler64 in this case).
I just built a copy of xpdf without libpoppler and the password
dialog works just fine.
Sources: https://github.com/hinki1/xpdf-nopoppler
To be built with: $ fakeroot debian/rules clean binary
Regards,
Matthias
Bug#606885: xpdf: no longer asks for password in dialog window
On Fri, Dec 01, 2017 at 12:17:52PM +0100, Florian Schlichting wrote: > the attached file requires the password 'secret' to open. there password_secret.pdf Description: Adobe PDF document
Bug#606885: xpdf: no longer asks for password in dialog window
I wasn't sure how to triage this bug without a password-protected
PDF file handy, but it turns out Libreoffice can create those. So for
the future, the attached file requires the password 'secret' to open.
xpdf will abort with an error ("Command Line Error: Incorrect password")
unless the correct password is supplied on the command line. This is
probably not very useful in cases where xpdf is not started from the
command line (web browser, graphical file manager, ...).
Patches welcome!
Bug#606885: xpdf: no longer asks for password in dialog window
found 606885 xpdf/3.04-4 thanks
Bug#606885: xpdf: no longer asks for password in dialog window
Package: xpdf Version: 3.02-11 Severity: normal Tags: security Hi Debian xpdf maintainers! Thanks a lot for maintaining my favorite PDF viewer! I noticed a little regression (probably introduced during the conversion into a libpoppler front-end). In the past, xpdf used to pop up a useful dialog window to ask the user for a password, when dealing with password-protected PDF files. After typing the password in, the user was able to view the contents of the password-protected PDF file. Nowadays, when the user attempts to view a password-protected PDF file, no dialog window is shown and xpdf exits immediately with the following error: $ xpdf protected_file.pdf Error: Incorrect password $ echo $? 1 On the other hand, if the user provides the correct password through the command-line option: $ xpdf -upw my_secret_password protected_file.pdf everything works fine and the file contents are correctly visualized. Of course, requiring the user to provide a password on the command line is not a good idea, from a security point of view: the password (in clear) is visible to anyone who takes a look at the screen, it's saved in the shell history, and so forth. As a consequence, I miss the old insert password dialog window! Could this feature be restored, please? Thanks for your time! N.B.: Before filing this bug report, I took a look at the already filed ones and noticed bug #601375. I thought it could be the same issue, but it probably isn't, since the file mentioned in that bug report gives me a different error message: $ xpdf HTUSA-EBU4-3.pdf Error: Weird encryption info Error: Incorrect password -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xpdf depends on: ii lesstif2 1:0.95.2-1 OSF/Motif 2.1 implementation relea ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.5-8 GCC support library ii libpoppler5 0.12.4-1.2 PDF rendering library ii libstdc++64.4.5-8The GNU Standard C++ Library v3 ii libx11-6 2:1.3.3-4 X11 client-side library ii libxt61:1.0.7-1 X11 toolkit intrinsics library Versions of packages xpdf recommends: ii gsfonts-x11 0.21 Make Ghostscript fonts available t ii poppler-data 0.4.3-1Encoding data for the poppler PDF ii poppler-utils 0.12.4-1.2 PDF utilitites (based on libpopple xpdf suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
