pdftk enforces lame pseudo-drm

Bug #127389 reported by Georg Sauthoff on 2007-07-21
12
Affects Status Importance Assigned to Milestone
pdftk (Debian)
Fix Released
Unknown
pdftk (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: pdftk

Hi,

(at least in Ubuntu 7.05 && pdftk 1.4)

well, pdftk honors some pdf flag by default, that says "don't let the user to process this pdf (like extract images) - only display the complete pdf (like in acroread)".

Because this annoys me very much, I wrote this really trivial patch for pdftk 1.2 to change the coded default. It is attached and works with pdftk 1.4, too.

Please apply.

Best regards
Georg Sauthoff

Georg Sauthoff (g-sauthoff) wrote :
Emmet Hikory (persia) wrote :

Thanks for the patch. While the password owner check is trivial to circumvent, it is part of the PDF spec, and so breaking the implementation is not something that would be done in Ubuntu. I've not been able to find a method to forward this patch upstream for consideration, but found a reference to what is perhaps reasoning behind the choice from http://www.lagotzki.de/pdftk/index.html#FAQ (German).

Changed in pdftk:
status: New → Won't Fix
Georg Sauthoff (g-sauthoff) wrote :

> Thanks for the patch. While the password owner check is trivial to circumvent, it is part of the PDF spec, and so breaking the implementation is not something that would be done in Ubuntu.

I was afraid you (the maintainer) would something like that. ;)

1) If you see it like this, ubuntu already breaks the PDF spec, because it ships kpdf, which includes the option 'obey drm limitations'. I didn't read the PDF spec, but probably it states, that a pdf-obey should obey drm limitation unconditionally.
2) The pdf spec is not holy. Specially ignoring the password owner check request, does not create problems (like creating non-conforming pdf documents). And if someone relies on the password owner check - well, that is not very intelligent.
3) Gentoo is not Ubuntu - but they integrated the patch into their pdftk package.
4) After having a quick glance at 3.5.2 of the pdf 1.7 spec, pdf tools are 'allowed' to do more with a pdfs than just displaying (additional operations), if the owner-pw is missing. What it is allowed depends on some attributes (user access permissions). And it looks like pdftk doesn't check this attributes and simply reject every operation if an owner pw is present (and not given at command line).

Regards
Georg Sauthoff

Emmet Hikory (persia) wrote :

Just to be clear, I don't mean to say that this change should not be done, that pdftk is a perfect example of an implementation of the spec, nor that Ubuntu seeks to enforce passwordIsOwner, but rather that I believe this is an upstream decision, and that fixing it on a distribution-by-distribution basis leads to inconsistent implementations of pdftk, which does not serve users best. Were I able to find a bugtracker for pdftk, I would forward your patch for consideration, especially given that pdftk fails to check any further attributes.

Maciej Pilichowski (bluedzins) wrote :

Gsauthof , I just wanted to say "thank you!" :-) -- great patch, works like a charm.

Changed in pdftk (Debian):
status: Unknown → New
Ulrich Lukas (ulrich-lukas) wrote :

Patch works well with pdftk-1.41 as of 2009-08-17.

Why not add a command-line option for this non-standards-compliant but highly useful functionality?

zxning@gmail.com (zxning-gmail) wrote :

Hi, Georg

This is exactly what I need. However patch and rebuild from source is out of my capacity.
Is it possible for you or someone upload a deb file for ubuntu 8.04? Or post details on how to build / compile ?

Thanks
Shawn

Changed in pdftk (Debian):
status: New → Confirmed
Changed in pdftk (Debian):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.