Skip to content
This repository has been archived by the owner on Nov 15, 2017. It is now read-only.

Extension Content Verification flag in Chrome Beta, Canary breaks HTTP Switchboard, uBlock #390

Closed
rusvnc opened this issue Jul 28, 2014 · 9 comments

Comments

@rusvnc
Copy link

rusvnc commented Jul 28, 2014

Just a heads up -- this flag is available in Chrome Beta and Canary at least, therefore must be in Dev channel as well (haven't checked Stable though). I do not know if it will be on by default in future releases of Chrome, but if enabled and set to enforce, it flags HTTP Switchboard, uBlock, HTTPS Everywhere, among others, as possibly corrupted by malware and disables them. (Once you have enabled the flag you can only recover by exiting Chrome and editing the Local State file to remove the extension-content-verification flag entirely (setting to 0 will hang the browser)). Uninstalling and reinstalling the tagged extensions then restores them.

This is the relevant flag:

Extension Content Verification Mac, Windows, Linux, Chrome OS
This flag can be used to turn on verification that the contents of the files on disk for extensions from the webstore match what they're expected to be. This can be used to turn on this feature if it would not otherwise have been turned on, but cannot be used to turn it off (because this setting can be tampered with by malware). #extension-content-verification

@gorhill
Copy link
Owner

gorhill commented Jul 28, 2014

I believe I fixed it with #379. I tested with Chrome 38 dev and it looks like it's fixed from my side. Did you try with release 1.0.0.3?

@rusvnc
Copy link
Author

rusvnc commented Jul 28, 2014

I will check when I get back to the machine where I can test it.

@rusvnc
Copy link
Author

rusvnc commented Jul 29, 2014

uBlock
HTTPSB
Chrome flag
Chrome Version

@gorhill
Copy link
Owner

gorhill commented Jul 29, 2014

I am going to have to investigate. It's really puzzling, as I removed all code which write using the File System API, now only the chrome.storage.local API is used, and this can't be the problem as this would probably break most extensions.

Did you re-install the extension from scratch?

When I tested last time I didn't get the warning. I will go try again.

I haven't seen any feedback from Chromium devs about this: http://code.google.com/p/chromium/issues/detail?id=389879

@rusvnc
Copy link
Author

rusvnc commented Jul 29, 2014

Yes I reinstalled. I also changed the settings (e.g. adding and removing
lists). It would seem poorly designed if their verification scheme did not
allow for preference changing. But could that be it?

It is fine IF you don't enable extension content verification in flags. But
it looks like they will implement that by default eventually.

@rusvnc
Copy link
Author

rusvnc commented Jul 29, 2014

This is probably a chrome bug.
On Jul 29, 2014 3:19 PM, "Raymond Hill" notifications@github.com wrote:

I am going to have to investigate. It's really puzzling, as I removed all
code which write using the File System API, now only the
chrome.storage.local API is used, and this can't be the problem as this
would probably break most extensions.

Did you re-install the extension from scratch?

When I tested last time I didn't get the warning. I will go try again.

I haven't seen any feedback from Chromium devs about this:
http://code.google.com/p/chromium/issues/detail?id=389879


Reply to this email directly or view it on GitHub
#390 (comment)
.

@gorhill
Copy link
Owner

gorhill commented Jul 29, 2014

Ok, I checked and using Chrome 38 dev, I got the same problem.

Now the next thing I think where the problem could be, is that for backward compatibility reasons, I still query the window.webkitRequestFileSystem, in order to move user data from the old location to the new one in chrome.storage.local.

It could be that merely calling window.webkitRequestFileSystem does create the root of the virtual file system, and just that causes the hash generated for content verification purpose to change. So next thing to try for me is to remove all the code left related to window.webkitRequestFileSystem. But whoever hasn't upgraded to 1.0.0.3 would probably lose data, not something I want.

And to make thing more complicated, I cannot even test this without publishing a version to the store, since the good hash is certainly generated by the store (locally installed copies are not flagged as tampered with).

If at least there was some detailed information about that content verification flag from the chromium devs, we would know what to do exactly. Maybe it's there somewhere and I just don't know where to find it. Currently I am left speculating about how I can fix this.

@rusvnc
Copy link
Author

rusvnc commented Jul 29, 2014

@gorhill
Copy link
Owner

gorhill commented Aug 2, 2014

Could be related to this:
Content verification handles 0-length files incorrectly.

There are zero-length files under assets/user/.

@gorhill gorhill closed this as completed in 19433f4 Aug 3, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants