Pdf.js: CSP violations for unsafe-inline in [email protected]

[tomtomau]

Configuration:

• Chrome
• Mac OSX
• PDF.js version: pdfjs-dist 2.0.943
• Is a browser extension: false

We have a content security policy that prevents unsafe-inline.

Unfortunately, after upgrading to 2.0.943, pdfjs-dist/build/pdf.js now has a Function("return this") call (which violates CSP.

My understanding was this was introduced when support for async/await and generators was added to the gulpfile.js.

Upon searching for the babel plugin and finding the GitHub issues, I find only two issues which don't really seem to be covering the issue.

I'm unsure of how to build my own version of pdfjs-dist to try and isolate to see if this is definitively the issue, so just posting this to see if I can get some help/pointers!

[Snuffleupagus]

I'm unsure of how to build my own version of pdfjs-dist to try and isolate to see if this is definitively the issue,

For debugging purposes it will be a lot quicker to just run gulp generic, rather than building the entire pdfjs-dist repo, and then check the pdf.js/pdf.worker.js files that are created in the build/generic/build/ directory.

Just make sure that you follow the steps outlined in https://github.com/mozilla/pdf.js#getting-the-code first, such that the repo is correctly setup locally and the various gulp commands will work.

[timvandermeij]

This is a part of generated code, so I don't think there is anything we can do about this. I would suggest to file this issue at the Babel repository instead. Thanks.

[sashapwc]

@tomtomau Have run into the same exact problem with the CSP violation on Function("return this") after upgrading and deploying to my server. My browser stops at node_modules/regenerator-runtime/runtime-module.js and there is an issue related to this. https://github.com/facebook/regenerator/issues/336

/**
 * Copyright (c) 2014-present, Facebook, Inc.
 *
 * This source code is licensed under the MIT license found in the
 * LICENSE file in the root directory of this source tree.
 */

// This method of obtaining a reference to the global object needs to be
// kept identical to the way it is obtained in runtime.js
var g = (function() { return this })() || Function("return this")();

The fix was merged I think in 0.12.1 https://github.com/facebook/regenerator/releases

Assuming this is caused by Babel's use of this library, I see the reference to this library in @babel/runtime (https://github.com/babel/babel/blob/master/packages/babel-runtime/package.json). Babel would need to update and then pdfjs would need to use the new version of babel to create the built version of the pdf.js file.

@timvandermeij Would you reconsider opening this as many of use the built viewer and I think we would need to rebuild the build/pdf.js file after babel is updated to use the newest version of runtime-module

[timvandermeij]

Thank you for looking into this. We regularly update our dependencies, so once Babel fixes this we will upgrade too.

[tomtomau]

@babel/runtime requires regenerator-runtime 0.12.0, which can resolve to 0.12.1 fine, however, that is only the case for babel 7.x

pdf.js is on Babel 6.26 which pins regenerator-runtime to 0.11

From my understanding - if pdf.js is upgraded to Babel 7.x this problem should be resolved.

[sashapwc]

@tomtomau I think you are right. I got stuck in dependency hell and didn't realize that yeah, the new babel should work. As a workaround, if you happen to be using the pre-built pdfjs viewer, you can find references to Function("this") and replace it with the code mentioned in https://github.com/facebook/regenerator/issues/336
There are three files: build/pdf.worker.js , web/viewer.js, build/pdf.js

[tomtomau]

Yeah thanks, we've just pinned to the older version of pdf.js for now

[sashapwc]

@tomtomau Looking at Babel's yarn.lock, they still aren't using regenerator-runtime 0.12.1, so I've written an issue there as well since they will need to explicitly yarn update to 0.12.1 or 0.13

Babel issue: https://github.com/babel/babel/issues/9043

[timvandermeij]

Reopening to track the Babel upgrade on our side. Feel free to ping us if the upstream fix is applied and we'll update too.

[timvandermeij]

The upgrade to Babel 7 is completed in #10293. Closing since there is nothing more we can do on our side now.