Bug#454140: pdftk: won't decrypt a PDF file
Julian Gilbey
Version: 1.41-2
I downloaded the file
http://www.cimt.plymouth.ac.uk/projects/mepres/book9/y9s10pba.pdf
and can read it fine using Acrobat reader on Linux (I will send you
the password privately). However the command
pdftk y9s10pba.pdf input_pw ***** output y9s10pba-nopw.pdf
gave the error message:
Error: Failed to open PDF file:
y9s10pba.pdf
OWNER PASSWORD REQUIRED, but not given (or incorrect)
Errors encountered. No output created.
Done. Input errors, so no output created.
Any suggestions what I might have done wrong or what I could do to fix
it?
Julian
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Aurélien GÉRÔME
thanks
On Mon, Dec 03, 2007 at 12:46:29PM +0000, Julian Gilbey wrote:
>I downloaded the file
>
>http://www.cimt.plymouth.ac.uk/projects/mepres/book9/y9s10pba.pdf
>
>and can read it fine using Acrobat reader on Linux (I will send you
>the password privately). However the command
>
>pdftk y9s10pba.pdf input_pw ***** output y9s10pba-nopw.pdf
>
>gave the error message:
>
>Error: Failed to open PDF file:
> y9s10pba.pdf
> OWNER PASSWORD REQUIRED, but not given (or incorrect)
>Errors encountered. No output created.
>Done. Input errors, so no output created.
>
>Any suggestions what I might have done wrong or what I could do to fix
>it?
On a first thought, I would say that the document uses an unknown
password encoding to pdftk.
On a side note, do you mind if the password were to be publicly given
on the BTS?
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys & Net Admin
Julian Gilbey
> On Mon, Dec 03, 2007 at 12:46:29PM +0000, Julian Gilbey wrote:
> >I downloaded the file
> >
> >http://www.cimt.plymouth.ac.uk/projects/mepres/book9/y9s10pba.pdf
> >
> >and can read it fine using Acrobat reader on Linux (I will send you
> >the password privately). However the command
> >
> >pdftk y9s10pba.pdf input_pw ***** output y9s10pba-nopw.pdf
> >
> >gave the error message:
> >
> >Error: Failed to open PDF file:
> > y9s10pba.pdf
> > OWNER PASSWORD REQUIRED, but not given (or incorrect)
> >Errors encountered. No output created.
> >Done. Input errors, so no output created.
> >
> >Any suggestions what I might have done wrong or what I could do to fix
> >it?
>
> On a first thought, I would say that the document uses an unknown
> password encoding to pdftk.
>
> On a side note, do you mind if the password were to be publicly given
> on the BTS?
I'd prefer not. This is a site with wonderful resources for school
use, but answers to several of the sections, as well as diagnostic
tests, are password protected. The password is only available to
schools. If anyone does require the password for diagnostics, they
can email either me or you.
Julian
Aurélien GÉRÔME
>On Mon, Dec 03, 2007 at 03:00:28PM +0100, Aurélien GÉRÔME wrote:
>> On a first thought, I would say that the document uses an unknown
>> password encoding to pdftk.
I just wondered for a moment whether this was not due to the fact
that pdftk no longer relies on the old embedded gcj/classpath source
code. Therefore I tested pdftk 1.40-2 on Etch, but it has the same bug.
The culprit is probably the iText library bundled with pdftk
which is quite old and its PDF encryption code located in
com/lowagie/text/pdf/PdfEncryption.java is probably out of
date. Perhaps working towards an update of that library (and hence
a port of pdftk to the last version of iText) would be the way to go.
There are a couple of annoying bugs like this one, I will see with
upstream what we can do about them...
>> On a side note, do you mind if the password were to be publicly given
>> on the BTS?
>
>I'd prefer not. This is a site with wonderful resources for school
>use, but answers to several of the sections, as well as diagnostic
>tests, are password protected. The password is only available to
>schools. If anyone does require the password for diagnostics, they
>can email either me or you.
OK.
Francesco Poli
[...]
> pdftk y9s10pba.pdf input_pw ***** output y9s10pba-nopw.pdf
>
> gave the error message:
>
> Error: Failed to open PDF file:
> y9s10pba.pdf
> OWNER PASSWORD REQUIRED, but not given (or incorrect)
> Errors encountered. No output created.
> Done. Input errors, so no output created.
[...]
I've just experienced this bug with another password encrypted PDF file
(that I can correctly read with xpdf).
On Mon, 3 Dec 2007 20:47:28 +0100 Aurélien GÉRÔME wrote:
[...]
> There are a couple of annoying bugs like this one, I will see with
> upstream what we can do about them...
Is there any progress on this?
--
http://www.inventati.org/frx/progs/scripts/pdebuild-hooks.html
Need some pdebuild hook scripts?
..................................................... Francesco Poli .
GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
Francesco Poli
> Hi!
Hello! :)
>
> On Sat, 03 Jul 2010, 13:01 +0200 Francesco Poli wrote:
> > On Mon, 3 Dec 2007 12:46:29 +0000 Julian Gilbey wrote:
> > > pdftk y9s10pba.pdf input_pw ***** output y9s10pba-nopw.pdf
> > >
> > > gave the error message:
> > >
> > > Error: Failed to open PDF file:
> > > y9s10pba.pdf
> > > OWNER PASSWORD REQUIRED, but not given (or incorrect)
> > > Errors encountered. No output created.
> > > Done. Input errors, so no output created.
> > [...]
> >
> > I've just experienced this bug with another password encrypted PDF file
> > (that I can correctly read with xpdf).
> >
> Thanks for you report.
You're welcome!
>
> Can you give me the version of pdftk you currently use
> (e.g. by running "dpkg-query -W pdftk"), please?
You're right: I forgot to mention that I am running Debian testing.
The pdftk version is 1.41+dfsg-8
The system information for the box where I encountered the issue is
pasted at the end of this message.
>
> If you want, you could send me the encrypted pdf file with the owner
> password. This would be helpful to narrow down this bug.
Unfortunately, that file includes reserved data: otherwise it would
*not* be password-encrypted! ;-)
I don't know if I am able to generate a test PDF file with the same
type of password-encryption... :-(
>
> > On Mon, 3 Dec 2007 20:47:28 +0100 Aurélien GÉRÔME wrote:
> > > There are a couple of annoying bugs like this one, I will see with
> > > upstream what we can do about them...
> >
> > Is there any progress on this?
> Upstream is unfortunately inactive for years.
> In the meantime, the Debian version of pdftk, which is now maintained by
> me, was heavily patched to support newer versions of the itext library
> and to fix a lot of bugs. But I can not replace upstream completely. Any
> help is welcomed.
I can understand...
I hope you can manage to fix the bug.
>
> Do you know the actively developed alternatives to pdftk like qpdf?
By taking a quick look at its documentation, it seems that it lacks
many useful pdftk features (concatenate PDF files, extract pages or
group of pages, ...).
Thanks anyway for pointing it out: it could be useful for other
purposes.
>
> Best wishes,
> Johann Felix Soden
Bye and thanks for your time.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
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 pdftk depends on:
ii libbcmail-java 1.44+dfsg-2 Bouncy Castle generators/processor
ii libbcprov-java 1.44+dfsg-2 Bouncy Castle Java Cryptographic S
ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib
ii libgcc1 1:4.4.4-5 GCC support library
ii libgcj-bc 4.4.4-2 Link time only library for use wit
ii libgcj10 4.4.4-3 Java runtime library for use with
ii libitext-java 2.1.7-2 Java Library to create and manipul
ii libitext-java-gcj 2.1.7-2 Java Library to create and manipul
ii libstdc++6 4.4.4-5 The GNU Standard C++ Library v3
pdftk recommends no packages.
Versions of packages pdftk suggests:
ii poppler-utils [xpdf-utils] 0.12.4-1 PDF utilitites (based on libpopple
-- no debconf information
Julian Gilbey
> > > > pdftk y9s10pba.pdf input_pw ***** output y9s10pba-nopw.pdf
> > > >
> > > > gave the error message:
> > > >
> > > > Error: Failed to open PDF file:
> > > > y9s10pba.pdf
> > > > OWNER PASSWORD REQUIRED, but not given (or incorrect)
> > > > Errors encountered. No output created.
> > > > Done. Input errors, so no output created.
> > > [...]
I have found a way of reproducing the error - I presume reliably.
Take an unencrypted PDF file.
Encrypt it using pdftk version 1.41 with a USER password only:
pdftk file.pdf output file-encrypt.pdf user_pw mypass
Now try to decrypt it using pdftk version 1.41 or even version 1.44:
pdftk file-encrypt.pdf input_pw mypass output file-dump.pdf
and you get the error:
Error: Failed to open PDF file:
file-encrypt.pdf
OWNER PASSWORD REQUIRED, but not given (or incorrect)
Even if you use the do_ask option, so that you are asked:
The password you supplied for the input PDF:
file-encrypt.pdf
did not work. This PDF is encrypted, and you must supply the
owner password to open it. If it has no owner password, then
enter the user password, instead. To quit, enter a blank password
at the next prompt.
Please enter the open password to use on the input PDF:
file-encrypt.pdf.
It can be empty, or have a maximum of 32 characters:
entering the user password still does not work.
Files encrypted using pdftk 1.44 do not have this issue.
Johann Felix Soden
on Su 12.12.2010, 21:58 +0000 Julian Gilbey wrote:
> I have found a way of reproducing the error - I presume reliably.
Thank you very much for analysing this bug.
I looked again at the code and library calls and I think I found now
now one reason why the owner password is reported as wrong:
pdftk versions from 1.41+dfsg-1 to 1.41+dfsg-9 use a newer version of
the itext library (libitext-java package) which sets sadly random owner
passwords if only an user password is given to its setEncrpytion
routine. The correct way for setting a user password but no owner
password would be to set the owner password equal to the user password
(this is sensibly prohibited by pdftk) according to the PDF Standard
[1].
Since this bug is reported to pdftk version 1.41-2, there must be
another encryption issue - but first I need to deal with the annoying
random owner password generation.
> Files encrypted using pdftk 1.44 do not have this issue.
pdftk 1.44 uses again its own bundled itext-paulo library which was
DFSG-cleaned and has not the generate random owner password "feature".
Best wishes,
Johann Felix
[1]:
http://partners.adobe.com/public/developer/en/pdf/PDFReference16.pdf