#485801 crippled with DRM anti-features

Package:
poppler-utils
Source:
poppler
Description:
PDF utilities (based on Poppler)
Submitter:
Robert Millan
Date:
2010-09-15 11:33:07 UTC
Severity:
wishlist
#485801#5
Date:
2008-05-14 12:01:16 UTC
From:
To:
This library appears to be crippled with DRM anti-features.  Here's a patch
to remove them.  Please apply it so that our users can exercise the fair use
rights they're entitled to.

#485801#12
Date:
2008-06-11 10:39:26 UTC
From:
To:
* Robert Millan <rmh@aybabtu.com>, 2008-05-14, 12:01:
[...]
But it is not. Functions, which the patch virtually disables, are never
internally used to disallow anything.

What is more, the patch breaks existing software, e.g. pdfinfo.

#485801#15
Date:
2008-06-11 13:03:51 UTC
From:
To:
I don't recall the exact details, but I've seen other programs rely on those
functions.  So they're not used internally, but externally.  IOW, it provides
a helper framework to facilitate implementation of restriction management in
an upper layer.

#485801#20
Date:
2008-06-11 13:43:12 UTC
From:
To:
2008/6/11 Robert Millan <rmh@aybabtu.com>:

So what? You are going to cripple the library just because another programs use
these functions? Patch those programs and not libpoppler then. It just provides
functions on top of PDF specs.

Ondrej

#485801#25
Date:
2008-06-11 14:10:32 UTC
From:
To:
* Robert Millan <rmh@aybabtu.com>, 2008-06-11, 15:03:
Right. pdftoabw and pdftohtml from poppler-utils use them to restrict
access (pdfimages, pdftops and pdftotext have been already patched not
to do that - see 02_permissions.dpatch.diff).

Tools from xpdf-utils do the same, although they are not linked with
poppler.

Don't hesitate to file bugs against _these_ packages.
It's nothing wrong with that, as long as you are free _not_to_ use the
framework.

#485801#28
Date:
2008-06-11 14:42:31 UTC
From:
To:
The PDF specs are supposed to describe how PDF is laid out, not how your
program should behave.  There's no reason you have to follow a spec on
things that are outside the scope of it.

For example, if RFC 821 said that messages containing the word "freedom"
should be automaticaly discarded, it would be silly for MTAs to implement
that, even if it's in a standard.

#485801#31
Date:
2008-06-11 14:51:24 UTC
From:
To:
In practice, it tends to generate confusion.  For example, the implementor of
a libpoppler-based program might naively think that access to the data is
disallowed by cryptography instead of restriction management, and make her
program disallow access to the document in good faith.

Or one could be writing a program that lists files and their properties, and
mistakenly tell the user that a PDF file cannot be printed.  This happened to
the KDE developers in fact:

http://bugs.kde.org/show_bug.cgi?id=162089

  (although they didn't want to recognize it)

If you don't want to remove the functions, please consider at least renaming
them and clearly documenting in the code that they're purely informative.

Thanks

#485801#34
Date:
2008-06-11 14:52:14 UTC
From:
To:
clone 481183 -1
reassign -1 poppler-utils
thanks

Doing. Thanks for the pointer.

#485801#43
Date:
2010-09-15 11:18:54 UTC
From:
To:
Today I stubled upon this crippling "feature" of poppler-utils.

I agree that the API shouldn't be changed (the API itself does not enforce
anything), but at least pdftohtml and pdftoabw should be patched.

Could you please add this patch to fix those two utilities?