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

Issue 444085 link

Starred by 7 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Oct 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Extension is disabled by content verification for all users (with CV enabled)

Reported by, Dec 19 2014

Issue description

Version: 40.0.2214.38 (Official Build) beta
OS: Mac OS X 10.9.5

What steps will reproduce the problem?
1. Ensure content verification is enabled in chrome://flags
2. Download

What is the expected output? What do you see instead?
Extension should be enabled.

Please use labels and text to provide additional information.
Extension is disabled after a short ~1 second delay, with "This extension may have been corrupted." listed below it in chrome://extensions. Repairing it results in the same scenario.


Comment 1 by, Dec 19 2014

For the record, this is the CRX file at the time of reporting.

Confirmed in Chromium 39.0.2171.96 on Linux.
86.7 KB Download
rob@: I've reported this bug in response to Peter's post:!topic/chromium-apps/FBlO8ITFEXw

Is the CRX you've attached the one that Peter is referring to?

Comment 3 by, Dec 19 2014

#2 Yes.
Hello. Happy New Year. What  is the status of this? I've discovered some users are able to install the extension and some are not(possibly due to chrome version?). 
About half of users have content verification turned on; the rest will be able to install the extension without a problem.

This bug is on our radar and asargent will be taking a look very soon.
ok thanks! looking forward to a fix. is content verification a user setting I can tell our users to toggle? Otherwise, my extension(and my business) is dead in the water until this is resolved :(
Yes, it can be turned off by changing the chrome://flags/#extension-content-verification flag to "Bootstrap" and restarting Chrome. However, this will leave your users vulnerable to other extension attacks. If you advise your users to go down this route, please have them reset the flag to "Default" after we have fixed this bug.
For what its worth, I switched the flag to bootstrap myself, restarted Chrome, and reinstalled the extension, but I'm still getting "This extension may have been corrupted." message.
Sorry, to be clear, the extension is still disabled.
This may be due to . Are you using a Linux or Windows machine?

If so, it may be that there is currently no way to turn off content verification. However, when we look into this bug we will try to identify the reason content verification is tagging your extension (e.g. we've experienced false tags with incorrectly formatted file paths before) and let you know so you can quickly push an update.
I'm on Mac OSX. Yes, I believe I'm experiencing  as well from the looks of it.
Switching to Bootstrap correctly turned of Content Verification for me.

Version: 40.0.2214.45 (Official Build) beta

Mac OS X 10.9.5
I'm on OSX 10.9.5, Chrome 39.0.2171.95 (64-bit). For further clarity, it appears like it switched the flag, but the extension still gives the corrupted message and is disabled.
When switching to Bootstrap mode, the current state of the extension will be maintained. The real test is after you go through the "Repair" flow from chrome://extensions. Is it still disabled after that?
Yes. Still disabled after going through "repair" as well as with full removal, chrome restart, and re-installation.
A potentially helpful finding from Viktar, who posted this on the original thread (!topic/chromium-apps/FBlO8ITFEXw):

Just fixed the same bug in my extension by cutting it piece by piece back to "hello world" application. The problem was in manifest, in capitalized folder name of icon paths: Images/icon.png
I recommend this way for you.
Just assumption, row from your manifest: "web_accessible_resources": [ "templates/users-show.html", "bower_components/jquery/", "templates/overlay.html", "templates/toolbar.html", "scripts/oauth2/oauth2.html" ]
"bower_components/jquery/" looks like mistake. As I can see from your folder structure should be "bower_components/jquery/jquery.min.js"
Wish you luck with your extension.
Unfortunately it did not work. Just published new version, and that version is appearing on Chrome store, but it is still disabled despite trying "repair" and doing a full re-install. 

Unfortunately, shotgun debugging is not feasible due to the size of the extension and the fact that the only way to determine whether a fix works is to upload and re-publish the extension.

I've tried to go through the manifest with a fine tooth comb and look for possible casing or path errors, but could not find anything obvious. 

If anyone knows a quicker way of testing whether an extension would trip the content verification feature flag, I'm all ears.

Thanks Chromium team for continuing to look into this!

Thanks again to the chrome team for continuing to look into this.
Sorry for the trouble this has caused you. 

From within your background page, you end up generating a reference to a slightly malformed url: "scripts//oauth2/adapters/doorkeeper.js" (which should really be "scripts/oauth2/adapters/doorkeeper.js"). It looks like this comes from line 101 in scripts/oauth/oauth2.js. This slightly malformed url is triggering a bug in our code which tries to figure out the expected contents of that file, and chrome ends up thinking it's an unknown file. If you fix the url generating code in your oauth2.js file, that should work around the bug in chrome until we have a fix released. 

Success! Thanks @asargent! This is actually totally understandable as a bug.  "//" should not be interpreted as a valid path. I just wish it would break on the dev side of life. :)

Anyway, thanks so much for the help everyone!

Comment 20 by, Jan 6 2015

That sounds concerning. When exactly is the bug that you describe triggered?
(e.g. when a non-existent extension resource is requested?)
By design, we want to disable the extension if it read a file that we didn't think should be present in the filesystem (eg a file that wasn't present in the webstore's copy of the extension source). 

The bug is that when we go to lookup the expected hash of the content for a relative file path of "scripts//oauth2/adapters/doorkeeper.js", we aren't finding it because of the "//". The root problem for this and similar bugs ( bug 437675  and  bug 439464 ) is that we begin with a URL, turn that into a relative file path, and then hand a string off to the OS, where the OS has some amount of leniency/strictness in resolving a relative path to an actual file. However we need to look up the hashes in a data structure keyed by relative path (kept in _metadata/computed_hashes.json), so we need to match the rules of the filesystem, and there have been a long tail of tricky edge cases. Some of these we can do a better job of warning developers about (eg see bug 29941 and  bug 428511 ) in advance, and some we can't. 

Comment 22 by, Jan 6 2015

Thanks for the clarification, so it only happens if an existing file is read with an unexpected path spec.

I'm glad that it does not get triggered upon access of a non-existent resource, because otherwise one of my extensions would break.
Just to be clear, if the source uploaded to the webstore has just 2 files:


and then at runtime the running script in background.js adds a script tag to reference some a file at relative path "foo.js", and a file named foo.js is successfully read (meaning foo.js was put there by some binary program outside of chrome), the content verification code will consider that to be corruption and disable the extension. This is done to prevent circumventing the security checks that we run on code submitted to the webstore. 

However, if there is no file named foo.js in the filesystem, the extension should not get disabled. (It's not immediately obvious to me why being able to try accessing a non-existent resource is useful; perhaps as a way to do a blocking XHR or something to workaround some limitation in the async nature of the platform?)

Comment 24 by, Jan 18 2015

 Issue 449097  has been merged into this issue.

Comment 25 by, Jan 18 2015

Deterministic steps to find out the cause of a disabled extension:

Enable logging, specifically for the content verification module.
On Windows, the log is written to a file, on Linux/Mac, the log can be printed to the standard error output (see for more details).

1. Start Chrome (from the terminal on Linux/Mac, via Windows+R on Windows):
   chromium --extension-content-verification=encorce --enable-logging=stderr --vmodule=*/
2. Visit the Chrome Web store and install the extension.
3. Observe that the extension is not installed.
4. Look at the log (Linux/Mac: stderr, Windows: log file)
5. Look for entries with failure reason 2. 1 is harmless, 2 indicates a missing file and 3 indicates a truly corrupted file.
Here is a fragment of the log for a similar bug report ( issue 449097 ):

[9124:9154:0118/] job failed for nmnbonfejofemjljdjagbjajfnalnmgh bower_components/lodash/dist//lodash.js reason:2
[9124:9124:0118/] VerifyFailed nmnbonfejofemjljdjagbjajfnalnmgh reason:2

6. Now you've found the trigger of the bug, check whether the path is in canonical form and fix it if needed ("dist//lodash.js" in the previous example looks bad, replace it with a single slash).

Comment 26 by, Jan 18 2015

Correction to step 1 of c25 (the last part of the line was missing):

chromium --extension-content-verification=encorce --enable-logging=stderr --vmodule=*/,*/
Status: Fixed
It turns out this problem was actually already fixed by for semi-related  bug 437675 , so marking as Fixed. 

Sign in to add a comment