Redistilling encrypted PDF is not permitted.

I manage a university-wide CUPS & Samba server and an occasional recurring

After checking out the PDFs being printed, I can confirm they have
password protections in place to prevent certain actions, but I'm confused
as to why it matters. The client was able to print them to the print
server, and if the client sends the job straight to the printer, there's
no problem. So why is it that this error only occurs when the CUPS server
tries to process it?
Any idea how I could make it process those jobs normally without throwing
that error and stopping the job?

The reason is that an encrypted PDF can be printed (preferably in
PostScript) but not (possilby modified) converted to PDF again. To achieve
this, Acrobat (and Adobe Reader) insert PostScript snippets into the
generated print job that lead to the error you mentioned.

There are two ways to get around this issue:

(1) Revert CUPS to using PostScript as the default print job language and
install the necessary filters.

(2) Edit your xxx.types and xxx.convs files and set up a document format
like
application/vnd.acrobat-postscript
by specifying the string "Creator: Adobe Acrobat" in the definition of this
document type, and set up your xxx.convs such that this document type
bypasses the pstopdf filter and uses only the pstops filter instead.

Helge

PS: bypassing the "redistilling brake" in the PS stream is quite tricky and
illegal in most countries due to the DRM regulations.

Renaud (Ron) Olgiati

2013-02-07 10:28:51 UTC

On Thursday 07 Feb 2013 06:43 my mailbox was graced by a message from Helge

Post by Helge Blischke
PS: bypassing the "redistilling brake" in the PS stream is quite tricky
and illegal in most countries due to the DRM regulations.

ISTR that the US of A are the only country afflicted with DMCA, which
crminalizes the bypassing of DRMs.

Cheers,

Ron.

--
Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our
country and our people, and neither do we.
-- President George W. Bush, Aug. 5, '04

-- http://www.olgiati-in-paraguay.org --

Benn

2013-02-11 23:41:06 UTC

I manage a university-wide CUPS & Samba server and an occasional recurring

After checking out the PDFs being printed, I can confirm they have
password protections in place to prevent certain actions, but I'm confused
as to why it matters. The client was able to print them to the print
server, and if the client sends the job straight to the printer, there's
no problem. So why is it that this error only occurs when the CUPS server
tries to process it?
Any idea how I could make it process those jobs normally without throwing
that error and stopping the job?

The reason is that an encrypted PDF can be printed (preferably in
PostScript) but not (possilby modified) converted to PDF again. To achieve
this, Acrobat (and Adobe Reader) insert PostScript snippets into the
generated print job that lead to the error you mentioned.
(1) Revert CUPS to using PostScript as the default print job language and
install the necessary filters.
(2) Edit your xxx.types and xxx.convs files and set up a document format
like
application/vnd.acrobat-postscript
by specifying the string "Creator: Adobe Acrobat" in the definition of this
document type, and set up your xxx.convs such that this document type
bypasses the pstopdf filter and uses only the pstops filter instead.
Helge
PS: bypassing the "redistilling brake" in the PS stream is quite tricky and
illegal in most countries due to the DRM regulations.

After posting this, I looked into the xxx.types and xxx.convs file and found
the override you're describing in 2 (perhaps added by default in some
distributions?). That part seems to be working as intended, too, because
printing any affected PDFs from Adobe Reader works as expected.

However, the issue has been occurring, and I suspect it's because printing
these PDFs from OS X Preview (or possibly other PDF viewers, like Google
Chrome) tags those PDF viewers as the creators instead of Adobe Reader. I
could just tell my users to use Adobe Reader, but I'd rather things "just
work," especially if it's really something the print server should be able
to handle.

Would my cleanest solution be the other option you've selected? Could I just
create a bash script to act as a "custom filter" that just checks for "eexec"
lines in the Postscript and calls the next filter (pstopdf or pstops) based
on whether or not that string is found?

Helge Blischke

2013-02-12 17:08:44 UTC

I manage a university-wide CUPS & Samba server and an occasional

After checking out the PDFs being printed, I can confirm they have
password protections in place to prevent certain actions, but I'm
confused as to why it matters. The client was able to print them to the
print server, and if the client sends the job straight to the printer,
there's no problem. So why is it that this error only occurs when the
CUPS server tries to process it?
Any idea how I could make it process those jobs normally without
throwing that error and stopping the job?

The reason is that an encrypted PDF can be printed (preferably in
PostScript) but not (possilby modified) converted to PDF again. To
achieve this, Acrobat (and Adobe Reader) insert PostScript snippets into
the generated print job that lead to the error you mentioned.
(1) Revert CUPS to using PostScript as the default print job language and
install the necessary filters.
(2) Edit your xxx.types and xxx.convs files and set up a document format
like
application/vnd.acrobat-postscript
by specifying the string "Creator: Adobe Acrobat" in the definition of
this document type, and set up your xxx.convs such that this document
type bypasses the pstopdf filter and uses only the pstops filter instead.
Helge
PS: bypassing the "redistilling brake" in the PS stream is quite tricky
and illegal in most countries due to the DRM regulations.

After posting this, I looked into the xxx.types and xxx.convs file and
found the override you're describing in 2 (perhaps added by default in
some distributions?). That part seems to be working as intended, too,
because printing any affected PDFs from Adobe Reader works as expected.
However, the issue has been occurring, and I suspect it's because printing
these PDFs from OS X Preview (or possibly other PDF viewers, like Google
Chrome) tags those PDF viewers as the creators instead of Adobe Reader. I
could just tell my users to use Adobe Reader, but I'd rather things "just
work," especially if it's really something the print server should be able
to handle.
Would my cleanest solution be the other option you've selected? Could I
just create a bash script to act as a "custom filter" that just checks for
"eexec" lines in the Postscript and calls the next filter (pstopdf or
pstops) based on whether or not that string is found?

AFAIK, this redistilling prevention is unique to Acrrobat /Adobe Reader.
Other PDF readers, like Mac OS X Preview etc., only check if printing is
allowed and then generate PostScript as usual, assuming that the PostScript
job is directed to the printer without further format change.

And yes, the mime type override is included by default in Ubuntu
distributions.

Helge

Benn

2013-02-12 18:19:53 UTC

I manage a university-wide CUPS & Samba server and an occasional

After checking out the PDFs being printed, I can confirm they have
password protections in place to prevent certain actions, but I'm
confused as to why it matters. The client was able to print them to the
print server, and if the client sends the job straight to the printer,
there's no problem. So why is it that this error only occurs when the
CUPS server tries to process it?
Any idea how I could make it process those jobs normally without
throwing that error and stopping the job?

The reason is that an encrypted PDF can be printed (preferably in
PostScript) but not (possilby modified) converted to PDF again. To
achieve this, Acrobat (and Adobe Reader) insert PostScript snippets into
the generated print job that lead to the error you mentioned.
(1) Revert CUPS to using PostScript as the default print job language and
install the necessary filters.
(2) Edit your xxx.types and xxx.convs files and set up a document format
like
application/vnd.acrobat-postscript
by specifying the string "Creator: Adobe Acrobat" in the definition of
this document type, and set up your xxx.convs such that this document
type bypasses the pstopdf filter and uses only the pstops filter instead.
Helge
PS: bypassing the "redistilling brake" in the PS stream is quite tricky
and illegal in most countries due to the DRM regulations.

After posting this, I looked into the xxx.types and xxx.convs file and
found the override you're describing in 2 (perhaps added by default in
some distributions?). That part seems to be working as intended, too,
because printing any affected PDFs from Adobe Reader works as expected.
However, the issue has been occurring, and I suspect it's because printing
these PDFs from OS X Preview (or possibly other PDF viewers, like Google
Chrome) tags those PDF viewers as the creators instead of Adobe Reader. I
could just tell my users to use Adobe Reader, but I'd rather things "just
work," especially if it's really something the print server should be able
to handle.
Would my cleanest solution be the other option you've selected? Could I
just create a bash script to act as a "custom filter" that just checks for
"eexec" lines in the Postscript and calls the next filter (pstopdf or
pstops) based on whether or not that string is found?

AFAIK, this redistilling prevention is unique to Acrrobat /Adobe Reader.
Other PDF readers, like Mac OS X Preview etc., only check if printing is
allowed and then generate PostScript as usual, assuming that the PostScript
job is directed to the printer without further format change.
And yes, the mime type override is included by default in Ubuntu
distributions.
Helge

Well, but if that were the case, then I wouldn't be having this problem. It
works as expected when printing from Adobe Reader. The print job only fails
with that message if it isn't.

As a test, I set up a fresh new Ubuntu CUPS server running the latest
packaged version of CUPS, and it's doing the exact same thing. I also tried
on both Snow Leopard and Mountain Lion. The resulting PostScript files (found
in the print server's spool directory) are here:

https://webdav.bennlinger.com/SL%20Example.ps
https://webdav.bennlinger.com/ML%20Example.ps

Setting CUPS to treat all PostScript like it does Adobe Reader PostScript
allows the job to go through, although this causes issues with unrelated
print jobs and also causes the printer to print (in addition to the
document itself):

ERROR: undefined
OFFENDING COMMAND: eexec

It seems like anyone supporting a large number of Macs with a CUPS server
would run into this issue. I'm not sure why there's not a clear and easy
solution.

Helge Blischke

2013-02-12 21:25:26 UTC