paperbackup-verify.sh may fail with operation not allowed by the security policy

[jose1711]

$ paperbackup-verify.sh foo.pdf
ERROR: attempt to perform an operation not allowed by the security policy `gs' @ error/delegate.c/ExternalDelegateCommand/378
..
diff and sha256sums do NOT match!

The fix (at least on my system) was to add

<policy domain="coder" rights="read | write" pattern="pdf" />

to /etc/ImageMagick-7/policy.xml. maybe add a remark into README?

[intra2net]

Thank you for informing us about this.

I haven't seen this issue yet. To me it looks like some security policy thing integrated into
ImageMagick, appearing when ImageMagick tries to work with pdf files. But I don't see an explicit call to ImageMagick in paperbackup-verify.sh.

What distribution are you using?

Would you mind to investigate a bit deeper where this happens? Is it in paperrestore.sh or in pdftotext?

Maybe there is an easy way to work around this. If not, we can always add something to the README.

[jose1711]

Looks like both zbarimg and pdftotext are using ImageMagick in some way. That means both restore and verify are affected.

$ zbarimg foo.pdf
ERROR: attempt to perform an operation not allowed by the security policy `gs' @ error/delegate.c/ExternalDelegateCommand/378

It may also be limited to Arch Linux and derivatives as per https://stackoverflow.com/questions/57208396/imagemagick-ghostscript-delegate-security-policy-blocking-conversion.

[kamalmostafa]

This affects a default installation on Ubuntu 22.04, Debian, and other OS's circa 2022. The problem is common (a common annoyance!) ;) See article referenced by @jose1711 and e.g. https://stackoverflow.com/questions/70655631/imagemagick-security-policy-error-in-github-workflow . It would make good sense to document the issue in paperbackup's README.

Note that my Dockerfile pull req address it by just removing the restrictive policy line from ImageMagick's config:

sed -i 's/^.*policy.*coder.*none.*PDF.*//' /etc/ImageMagick-6/policy.xml