Hi Ryan,

Thanks for the bug report. We have some logic which tries to detect corrupted extension files - it compares the contents of the files to the files uploaded to the webstore.

In your case, it sounds like the only change was to the manifest.json file. By itself, this isn't cause for the extension to be marked as corrupted and sounds like a bug.

You mentioned that the extension was installed by enterprise policy. Would you be able to add some details on how this was done? More specifically:
* Which policy you are using (ExtensionSettings? ExtensionInstallForcelist?)
* The update_url used by the policy. 
* If the update_url is not https://clients2.google.com/service/update2/crx, the contents of the XML file that it's pointing to. 
* If the XML file contains an "appid", could you confirm that its the expected id?
* If the XML file contains a link to a .CRX file, could you try to download it and confirm that it doesn't have any changes compared to the version in the webstore? (You should be able to open it with 7zip) 

Thank you

* Which policy you are using (ExtensionSettings? ExtensionInstallForcelist?)
     -ExtensionInstallForcelist is being used to push the extension.
* The update_url used by the policy. 
     - Using the standard: https://clients2.google.com/service/update2/crx

In addition, we are having the same experience when trying to install an extension from the public web store on a personal account (not pushing via policy)
https://chrome.google.com/webstore/detail/dynamic-web-twain/ejogmcjccgpfiiicpldnljpnigmgjibj?utm_source=chrome-app-launcher-info-dialog

For #1 (https://chrome.google.com/webstore/detail/test-service-nsw-kiosk-ut/onabolffhogbbkjjhekclkagihbbfagh), I was able to see the corruption when downloading the extension from the webstore.

For some unknown reason, ContentHash::CreateHashes sets three values in hash_mismatch_unix_paths_:
{path_=L"_metadata/verified_contents.json" } (bad)
{path_=L"images/SNSW1.png" } (ok)
{path_=L"manifest.json" } (ok)

I don't know enough about ContentHash to speculate on why that might be. Re-assigning to @lazyboy who knows a lot more about verified_contents. 

For #4 (https://chrome.google.com/webstore/detail/dynamic-web-twain/ejogmcjccgpfiiicpldnljpnigmgjibj), could you double-check on different computers? I tried installing the extension and did not notice any issues on Chrome Stable 64.0.3282.140 

#5 - I can verify that installing & running the extension on either my personal or GSuite account on a Windows machine works as expected. The same test on a CrOS machine does NOT work (either account, same experience). Seems to be localised to ChromeOS rather than profile on face value.

Had some more time to investigate. For #1:

For some strange reason, the extension somehow has two copies of the verified_contents.json file (with different contents - see attached screenshot). I assume that the extension was somehow uploaded to the webstore with a verified_contents file already. I'm not too familiar with uploading extensions, but I would hope that we have some error messaging during upload when that occurs. 

The CRX file can contain two files with the exact same path/name (that's apparently something zip files can do ?!?!?). However, when the extension is unpacked into a folder, only one of the verified_contents.json file can be present in the file system. The wrong one is somehow picked - leading to corruption. 

Deleted: onabolffhogbbkjjhekclkagihbbfagh_crx.png 15.8 KB

	onabolffhogbbkjjhekclkagihbbfagh_crx.png 15.8 KB View Download

This seems like a server-side issue in the Chrome Web Store's CRX packing mechanism. +cc @waffles who knows more about CRX packing.

For your extension - the good news is that the prod version (obicpkkbfhkiglmhejebnncjbplldahb) does not have a duplicate manifest and probably won't have the same issue when updated. To be safe, do not include the _manifest/ folder as you're uploading the extension to the CWS. 

You should be able to fix the test version of the extension by uploading a new version of the test extension without the _manifest/ folder.

Have uploaded a new version without including the /_metadata folder (assuming this is what was meant by the previous comment) and can confirm this fixes the issue.

Yes, that's indeed what I meant. Thanks for your patience! I'm glad this fixed your issue.

Keeping this bug open until we fix the server-side issue.