New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 880813 link

Starred by 8 users

Issue metadata

Status: WontFix
Owner:
Closed: Sep 6
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Upgrade to 69 made our extension unable to load

Reported by ofekshi...@gmail.com, Sep 5

Issue description

Chrome Version       : 69.0.3497.81


What steps will reproduce the problem?
(1) Build any toy extension, in its manifest.json include: 
...
	"background": {
		"persistent": true,
		"scripts": ["background.js"]
	},
...
	"content_security_policy": "script-src 'none';
...

(2) Add the extension to chrome 68. Everything runs fine
(3) Add the extension to chrome 69. Open the extension's background page.


What is the expected result?
The extension was able to load and run.

What happens instead?
On chrome *69 only*, the extension fails to load and console at the background page shows (with my particular ext id):

Refused to load the script 'chrome-extension://gpdhifpjckmgifbagfkfbkghcpphopce/background.js' because it violates the following Content Security Policy directive: "script-src 'none'".

'none':1 Failed to load resource: net::ERR_FILE_NOT_FOUND



 
Bisected to 38d9d19a09dd6d90ab023d4d83e7bf6bc9d5731f = https://crrev.com/c/1116065
"Prevent Javascript URLs from executing on chrome-extension scheme pages."
Landed in 69.0.3489.0

Repro: install the attached extension
Expected: 'success' is shown in a popup
Observed: nothing happens
test-ext.zip
513 bytes Download
Labels: Hotlist-ConOps
Components: Platform>Extensions
Labels: -Type-Bug Type-Bug-Regression
Owner: dbertoni@chromium.org
Status: Assigned (was: Unconfirmed)
Thank you for taking this seriously. Can we expect a chrome 69 update with a fix?  Approximately when?
Cc: pbomm...@chromium.org gov...@chromium.org
Labels: -Pri-3 ReleaseBlock-Stable M-69 Target-70 Target-71 RegressedIn-69 FoundIn-71 FoundIn-70 hasbisect Target-69 FoundIn-69 OS-Linux OS-Mac Pri-1
Reporter, there's no guarantee the fix makes it into 69 because the stable channel gets updates quite rarely and only for critical stuff (like crashes, security, etc.) that affects lots of people. Can you modify your extension's CSP? There should be no need for such a restrictive rule. If you want to run some third-party code in the extension page context, you should do it in a sandboxed page/iframe instead, see http://developer.chrome.com/extensions/sandbox
@woxxom, our extension is installed on >1M endpoints, many of which have little or no www access (installations not via the chrome store), and with quite a few extension versions to patch.  Currently every endpoint that upgrades to 69 breaks our product, due to this chrome regression. 

So while we can work around this regression we'll have a hard time distributing it in a timely manner. And paying customers continuously lose functionality due to this bug.
We respectfully urge you to reconsider and issue a chrome fix.

Cc: devlin@chromium.org
Cc: mkwst@chromium.org
Labels: -ReleaseBlock-Stable OS-Chrome
This seems to be working as intended.  `script-src 'none'` means *no* script should be allowed to execute on the page, including the script from the page itself.  `script-src 'self'` allows scripts from the same origin to be loaded, and no others.  You could also add specific scripts, like chrome-extension://<id>/script.js.

Prior to revision 38d9d19a09dd6d90ab023d4d83e7bf6bc9d5731f, there was a bug where CSP rules were being (incorrectly) ignored.

It seems like the right fix here would be to specify script-src 'self' or script-src <your scripts> in the CSP of the extension.  Will that work, or is there something I'm missing?

Removing ReleaseBlock-Stable for now.
Status: WontFix (was: Assigned)
As Devlin stated, the right fix is to update the CSP.
A solid case could be made that since an extension is pure script there is no meaning to script-src 'none' for an extension and chrome should special case 'none' when used in this context.

More importantly, it seems clear that setting this behaviour was never the intended goal for this commit and it is a side effect of some other change. Please consider that backward-compatibility and avoiding breaking customer code in the field might take priority here.   As noted above, deploying the suggested extension fix (more like a workaround) involves patching multiple extension versions and deploying to private stores, and is far from straightforward for us.

>A solid case could be made that since an extension is pure script 

I guess you meant "an extension's background script is pure script" but it's an incorrect assumption.

The background page of an extension is neither a DOM-less WebWorker nor an abstract "something that runs scripts", it's a standard DOM page and it's always constructed even if you use the modern syntax with just "scripts" inside manifest.json's "background" section instead of "pages" or the ancient "background_page". That's how extensions always worked since the background pages were introduced in the extension API. If you examine such autogenerated background page in devtools you'll see it is standard DOM with the <script> elements pointing to the scripts listed in manifest.json.

>More importantly, it seems clear that setting this behaviour was never the intended goal for this commit and it is a side effect of some other change.

Your extension relied on a bug in the browser's handling of CSP for extensions, and the bug was accidentally fixed by this commit.
This is an unintended, breaking change, in a non-standardized area where the right thing to do is debatable.  Many other vendors are known to prioritize keeping cusomers' existing code working in such cases. It would be disappointing if google elected otherwise.

> non-standardized area where the right thing to do is debatable

What is this "non-standardized area"?
Do you mean the fact that the background pages are standard DOM pages?
If so, I can agree the documentation is vague and it probably became even more vague after the last simplification.
As woxxom@ points out, background pages are implemented as standard DOM pages, and CSP should be applied to them in the manner described in the CSP spec.  According to that spec, script-src 'none' will prevent any script from executing.

Out of curiosity, what was the intended effect of including script-src 'none', or what would the expected behavior have been?
The intention was of course that no other script would be able to run. That
worked for many versions.

בתאריך שבת, 8 בספט׳ 2018, 17:48, מאת rdevlin.… via monorail ‏<
monorail+v2.1119303457@chromium.org>:
Per the CSP spec, if you want to allow the origin to run but no external scripts, you should specify 'self', rather than 'none'.  Updating your extension to do that should fix the issue.

Sign in to add a comment