Status Update
Comments
ve...@google.com <ve...@google.com> #2
Hello,
Thank you for reporting this issue. I have forwarded the details to the Cloud Functions engineering team, and it's currently being investigated.
Further communications will be made in this thread, however I cannot promise an ETA for the resolution of this issue.
Thank you for your understanding.
kr...@sagura.fi <kr...@sagura.fi> #3
Is there any update on this ticket?
This bug is related to an outdated permission policy which was confirmed (and already fixed on later release) on 08/2019 by the creator of Fred's ImageMagick
It should be fixed as soon as possible as it's one of the core features when converting PDF files to images.
We have tested and confirmed this bug multiple times in our development environment. This small fix is crucial to our next product update which we are releasing on 01/09/2020.
Hope to hear from you soon. Thanks and regards!
kr...@sagura.fi <kr...@sagura.fi> #4
We still need this issue to be fixed. Any updates...?
[Deleted User] <[Deleted User]> #5
I would like to echo the concerns listed above as I am another user being affected by this issue.
My cloud function requires a PDF output to a GCP cloud bucket.
Currently, this ticket is blocked by an internal google issue, would you be able to provide us insight on this blocker?
Thanks!
hj...@google.com <hj...@google.com> #6
Hello,
Thank you for your ongoing patience.
The Cloud Functions engineering team is currently working to fix this issue, unfortunately there is not any ETA for the fix.
I understand that this issue is affecting your applications, as a workaround you can use google
In this
fa...@gmail.com <fa...@gmail.com> #7
This issue is also blocking development. Any updates on the fix?
Thanks
kr...@gmail.com <kr...@gmail.com> #8
Is there any update on this? This is still an issue to our development.
As a workaround, we are currently using an external service, where we upload our PDFs and convert them to images. We would like to use ImageMagick image processing as it's faster and more scalable. We don't want to deploy external servers using docker image as we would need to maintain them closely.
Hope to get hear some updates soon! :)
Thanks!
ro...@google.com <ro...@google.com> #9
Hi everyone
the engineering team is still taking a look at this, but I am sorry to say that at the moment they have not provided any ETA for the resolution of this. We will keep you informed about it.
[Deleted User] <[Deleted User]> #10
I too just ran into this issue and I'm in need of using imagemagick to convert a pdf into an image. Is there any update on this?
da...@budnick.ca <da...@budnick.ca> #11
Hello all,
As per the suggestion of google you should move towards using Cloud Run instead of Cloud Functions as you are able to containerize your own application runtime using Docker. You will have control of the exact dependencies, in the current case the latest patched version of imagemagick.
Here is a snippet from my Dockerfile which I use in my application when building it for Cloud Run.
FROM alpine:3
RUN apk add --no-cache imagemagick
RUN apk add --no-cache ca-certificates
Thanks!
Description
Functions log following error to stderr:
stderr: 'convert-im6.q16: not authorized `/tmp/dummy.pdf\' @ error/constitute.c/ReadImage/412.\nconvert-im6.q16: no images defined `/tmp/dummy.jpg\' @ error/convert.c/ConvertImageCommand/3258.\n'
After some debugging it would seem that this is caused by permissions set to ImageMagicks being too strict. This is probably due to severe security vunerability that package called Ghostscript had. ImageMagicks uses Ghostscript behind the scenes to process PDF files.
Due to Ghostscript's severe security vunerability ImageMagick shipped with restricted access to PDF files. However, as stated by creator of ImageMagick these restrictions can be relaxed if Ghostscript version 9.25 or newer is installed (see
GCF uses Ghostscript version 9.26 (2018-11-20), as logged by using command "gs -h". Therefore PDF restrictions could be relaxed and it would allow to rasterize PDF files on GCF via ImageMagick. Permissions are stored in policy.xml file (in /etc/ImageMagick-6/policy.xml I believe). Required changes would be:
Change:
<policy domain="coder" rights="none" pattern="PS" />
<policy domain="coder" rights="none" pattern="EPS" />
<policy domain="coder" rights="none" pattern="PDF" />
<policy domain="coder" rights="none" pattern="XPS" />
To:
<policy domain="coder" rights="read|write" pattern="PS" />
<policy domain="coder" rights="read|write" pattern="EPS" />
<policy domain="coder" rights="read|write" pattern="PDF" />
<policy domain="coder" rights="read|write" pattern="XPS" />
Cloud Function code to reproduce issue:
const admin = require('firebase-admin');
const path = require('path');
const os = require('os');
const spawn = require('child-process-promise').spawn;
const dummyPdfPath = path.join(os.tmpdir(), 'dummy.pdf');
const imageFilePath = path.join(os.tmpdir(), 'dummy.jpg');
// admin.initializeApp(...);
// dummyPdfPath can be replaced with absolute path to PDF in local environment, storage bucket download is used just for easy access to PDF when function is deployed
await admin.storage().bucket().file('dummy.pdf').download({
destination: dummyPdfPath
})
await spawn(
'convert',
[dummyPdfPath, imageFilePath],
{capture: ['stdout', 'stderr']}
);