+Devlin to triage

Does any custom signed CRX reproduce the issue, or your specific one reproduces the issue?

Hi there, 

We've tried the same procedure on another self-signed extension and it does not work either. 

The signing was done with a bash script which is attached to this comment. 

Please let me know if you need more information.

Deleted: buildCrx.sh 1.4 KB

buildCrx.sh 1.4 KB View Download

There's a few underlying issues here, I think.

The biggest hurdle here is that Chrome doesn't allow off-store extensions (on Mac, Windows, and CrOS, at least), except for special circumstances (like a policy-installed extension).  As such, adding the packed CRX to chrome will result in the extension being disabled.  For development, it's usually best to load the extension as an unpacked extension.

That said, the corrupted error here really isn't very helpful.  Instead, it should say something like "not from web store".  proberge@, my guess is that this is because we have the following lines in InstallVerifier::IsFromStore():

  // If an extension has no update url, our autoupdate code will ask the
  // webstore about it (to aid in migrating to the webstore from self-hosting
  // or sideloading based installs). So we want to do verification checks on
  // such extensions too so that we don't accidentally disable old installs of
  // extensions that did migrate to the webstore.
  return (ManifestURL::GetUpdateURL(&extension).is_empty() &&
          Manifest::IsAutoUpdateableLocation(extension.location()));

This means that an extension not specifying the update URL will be considered from the store, so will pass InstallVerifier, but won't pass content verification.  I know we talked about whether or not we could remove these - I wonder if it's worth doing.  Any thoughts?

Note that this would *not* result in the extension not being disabled, because it still isn't from the store, but it's at least clearer messaging.

To folks experiencing this - what's the reason for not loading an unpacked extension for development?

Actually it should load and give a message like "not from the web store". May be local hash checking would be a good way to verify at least the contents are not modified arbitrarily as with the other extensions. 

As one of the folks to experience this, I would like to/need to load policy-installed packed extensions because Chrome itself would disable unpacked exts after browser restart and say those were disabled not to reduce performance or sth like that and you'd have to re-enable dev mode and reload them. In addition to this, in-house custom packed extension usage would be useful for some institutions, that's one of the reasons why policies exist. So I'd assume people would prefer a "not from store" warning with content verification rather than disabling and forcing for dev mode usage.

Chrome does allow policy-installed extensions that are not from the webstore.  If you are loading an extension using domain policy and Chrome is disabling it, that's a (separate) bug.  From the original report here, it didn't sound like that was the process.  If you're seeing that behavior, please file a new issue at crbug.com/new.

> Chrome itself would disable unpacked exts after browser restart and say those were disabled not to reduce performance or sth like that and you'd have to re-enable dev mode and reload them.

We should never do this, either.  We *do* warn when you have unpacked extensions, but they should not be automatically disabled.  Similarly to above, if you're seeing this and can reproduce, please file a new bug.

I apologize to everyone whose workflow was negatively impacted by this change. As Devlin explained, Chrome typically doesn't allow off-store extensions to be loaded outside of enterprise/policy contexts. We believe that the behaviour change (making it harder to load off-store extensions) is intended and does not constitute a regression. 

Please let us know if the alternative presented (loading the unpacked extension) is viable for your QA workflow. 

@Devlin the messaging change suggested in #6 seems reasonable. You mentioned wanting to get rid of that migration logic eventually; we might as well try to do it now. 

Hi, 

In fact, we are using a crx because we need the extension to have the same id on all our machines. We tried to make our extension have a unique id in unpacked mode but didn't manage to do so. 

I believe there's a documentation about how to get our unpacked extension to have a unique id out there that we didn't find? 

@11: Check out https://developer.chrome.com/extensions/manifest/key.  It's pretty sparse, but should work for your needs.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/63405aa4ef5bd5f0191e73c9d4c21711487b8215

commit 63405aa4ef5bd5f0191e73c9d4c21711487b8215
Author: proberge <proberge@chromium.org>
Date: Sat Oct 21 02:14:57 2017

Install verifier: Remove migration logic from IsFromStore

Bug:  775860 
Change-Id: I57198b52cc013bc2a9cb9544894451b297b4e49b
Reviewed-on: https://chromium-review.googlesource.com/729239
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Commit-Queue: proberge <proberge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510644}
[modify] https://crrev.com/63405aa4ef5bd5f0191e73c9d4c21711487b8215/chrome/browser/extensions/install_verifier.cc

@12 Thanks, it looks like it's exactly what we were looking for!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4c8e102e00db2cbe0d3189e71bd5d450d93eaf55

commit 4c8e102e00db2cbe0d3189e71bd5d450d93eaf55
Author: Hans Wennborg <hans@chromium.org>
Date: Mon Oct 23 10:25:52 2017

Revert "Install verifier: Remove migration logic from IsFromStore"

This reverts commit 63405aa4ef5bd5f0191e73c9d4c21711487b8215.

Reason for revert:
It broke browser_tests in chrome-branded builds (see bug).

Original change's description:
> Install verifier: Remove migration logic from IsFromStore
> 
> Bug:  775860 
> Change-Id: I57198b52cc013bc2a9cb9544894451b297b4e49b
> Reviewed-on: https://chromium-review.googlesource.com/729239
> Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
> Commit-Queue: proberge <proberge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#510644}

TBR=rdevlin.cronin@chromium.org,proberge@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  775860 ,  777297 
Change-Id: Icf1ee4c5c6fea2a09456375f69e64ba9274bae6c
Reviewed-on: https://chromium-review.googlesource.com/732937
Reviewed-by: Hans Wennborg <hans@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510754}
[modify] https://crrev.com/4c8e102e00db2cbe0d3189e71bd5d450d93eaf55/chrome/browser/extensions/install_verifier.cc

This issue is extremly critical for our company. I am still able to reproduce this issue on Chrome beta 63.0.3239.30 .

Hi @terekhovm, I'm sorry to hear that this is causing an issue for your company.

Are you seeing the same issue as described in #1 (internal QA team cannot load a packed Chrome extension)? If so, does the alternative in https://bugs.chromium.org/p/chromium/issues/detail?id=775860#c12 (having your QA team load an unpacked extension specifying a manifest key to control the extension id instead of trying to load a packed extension) solve your problems?

If the suggested alternative doesn't work or you are seeing a different issue, please let me know and we'll try to find a solution that works for you. 

Hello @proberge,
The extension is the part of our product. We register the extension (crx) in the Windows Registry during product installation.
Such extensions are disabled by default, so we published some initial version of extension with the same appid in GWS to provide user friendly way to install extension to our customers.
When user updates the product -- crx file is updated too, also version in its manifest.json is changed.
Versionning is very important for us, we release many versions of product per year with some changes in the extension and we should support all that versions.

Now our extension is marked as corrupted in Chrome 63, but it still works in Chrome 62.
So, this issue is very critical for us.
Other ways to solve this issue do not work:
* We are unable to enable extensions via group policies because of bug https://bugs.chromium.org/p/chromium/issues/detail?id=173640
* GWS limit is 20 extensions per account, we produce much more versions of extension every year. So, we are unable to publish every version as new version in GWS. I guess it is not very good for Store.

Could you please suggest us some another alternative or fix this issue?
Thank you.

#18 - this does not seem like an appropriate conduct (you kind of hacked the system).
I do not think the goal of the validation was to make sure any version exists in the web store - it was to make sure the installed extension (plus its version) is from the web store, just installed using the registry.

> * GWS limit is 20 extensions per account, we produce much more versions of extension every year. So, we are unable to publish every version as new version in GWS. I guess it is not very good for Store.

There is no limit to the number of versions, as far as I know, only to the number of extensions, so I do not understand this issue.

#19
> There is no limit to the number of versions, as far as I know, only to the number of extensions, so I do not understand this issue.

We need specific version of extension for every product version.
Early product (ver A) should use extension ver X.
New product (ver B) should use extension ver Y, it does not work with ver X!
Early product (ver A) does not work with extension ver Y!

Is it possible to implement such versioning (X, Y, ...) for single extension appid?
I yes -- it's ok. Otherwise we should create new extension every time and Store limit is critical for us.

No, that is not possible. Sounds like tailored extensions. You should not use versioning, but different extensions.
While you are limited to 20, you can get more by filing a ticket, using the general developer form - https://support.google.com/chrome_webstore/contact/developer_support
Also, perhaps you should use the Google Apps Chrome Web Store that creates a private store for your organization (and maybe there are no limits?), not sure whether you can publish organization extensions that can be used by other organizations, you will need to investigate.

This issue breaks our test and deployment process. We need a lot of versions of the same extension. After your changes we have to create a new one each time when we create a new version. Our customers use different versions of our desktop application. Each version of this desktop application have to work with a certain version of our Chrome extension. We cannot update an existing extension because this breaks already installed desktop application.

We cannot use group policies because of https://bugs.chromium.org/p/chromium/issues/detail?id=173640

Please fix at least one of this issues as soon as possible.

Hi Eugene and @terekhovm,

I think I understand your versioning issues. One problem is that the Chrome Web Store was built with the assumption that extensions should update automatically. This allows users to get new feature and bug fixes while easing maintenance burden on developers since they only need to support the latest version. 

I assume there are other complications preventing you from having your extension contact one of your servers to determine which functionalities it should provide to the user's installed product version? 

Another alternative for your enterprise users is to use an off-store extension which won't trigger corruption checks. You could even host your own webstore server and point the extension's webstore_update_url to your server to control which version each user should update to. 

You both linked https://bugs.chromium.org/p/chromium/issues/detail?id=173640. From what I understand, group policy installations work correctly except you do not have the ability to enable the extension for file:// urls and incognito windows. I can think of a few use cases (such as parental control software) where this could be business critical. Perhaps in those cases you could disable incognito mode through the group policies?

There seems to be some interest from other developers in making file:// urls work. However, even if it gets implemented now, it probably won't be included in either M63 or M64. 

Marking as Won't fix - Working as intended.

Please re-open this bug if you see extension corruption messages you believe should not be happening.

> Chrome does allow policy-installed extensions that are not from the webstore.  If you are loading an extension using domain policy and Chrome is disabling it, that's a (separate) bug.  From the original report here, it didn't sound like that was the process.  If you're seeing that behavior, please file a new issue at crbug.com/new.

Hi, I've just came across this very same problem when running Chrome 63 today in Endless OS [1], where we pre-install an extension that is part of our product: prior to Chromium/Chrome 63, we could have this extension enabled without issues, but with Chrome 63 it shows up as "This extension might have been corrupted" and can't be enabled.

If I try to enable it with a ExtensionInstallForcelist policy, however, I can get chrome://extensions to show me the extension without errors (indicating that it's being "managed and cannot be removed or disabled"), but it doesn't allow me to enable it.

Since our extension is very tied to the particularities of our OS, we haven't published it in the Chrome Web Store, but from what I'm reading here and in other places I found searching around (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=794219), it looks to me like this might be expected: extension not in the CWS -> Can't be enabled?

However, this particular comment (https://bugs.chromium.org/p/chromium/issues/detail?id=775860#c9) makes me think I might be missing something, since apparently it should still be able to enable such extension, even if not in the CWS, when installed with a group policy.

Could anyone clarify what the expected result would be in this case?

This is on a x64_64 build of Chrome for Linux, by the way :-)

Thanks in advance,
Mario


[1] https://endlessos.com

Hi Mario,

On Linux, non-CWS extensions are allowed. A bug in Chrome 63 (https://bugs.chromium.org/p/chromium/issues/detail?id=794219) is causing some non-CWS extensions to get disabled. The issue also disables some group-policy-enabled extensions.

A temporary workaround until M64 is to provide an update-url in your extension's manifest. Any update-url will do, but I suggest providing a real one so you have a way to update your extension.
See https://developer.chrome.com/apps/autoupdate for more information.

Hi @proberge,

> On Linux, non-CWS extensions are allowed. A bug in Chrome 63 (https://bugs.chromium.org/p/chromium/issues/detail?id=794219) is causing some non-CWS extensions to get disabled. The issue also disables some group-policy-enabled extensions.

Ah! I see now... I suffered a bit of "information overload" when looking into this before and didn't notice that such bug (which you will see linked in my previous commend!) was precisely about that. Good to know, thanks!

> A temporary workaround until M64 is to provide an update-url in your extension's manifest. Any update-url will do, but I suggest providing a real one so you have a way to update your extension.

I tried adding an URL both after the `;` in the policy's json file (right after the id), as well as in the manifest.json for the extension, but neither way I managed to get it enabled in Chrome or Chromium 63.

For reference, this is how my policy.json file looks: 
```
{
    "ExtensionInstallForcelist": [
        "fpmnjlkappdkncfmjefheaidpmbmfdfk;https://www.endlessm.com"
    ]
}
```

And this is how the manifest.json file looks for the extension:
```
{
  "name": "Exploration Center",
  "version": "1.0.1513609712",
  "permissions": [
    "bookmarks",
    [...]
    "nativeMessaging"
  ],
  "chrome_url_overrides" : {
    "newtab": "index.html"
  },
  "content_scripts": [
    {
      "css": [
        "css/adwaita_scrollbars.css"
      ],
      "matches": [
          "<all_urls>"
      ],
      "exclude_matches": [
          "*://mail.google.com/*"
      ]
    }
  ],
  "manifest_version": 2,
  "content_security_policy": "script-src 'self' 'unsafe-eval' https://ajax.googleapis.com; object-src 'self'",

  "web_accessible_resources": [
    "index.html",
    "css/style.css",
    "img/background.png",
    "img/line-division.png",
    "img/sprites.png",
    "favicon.ico"
  ],

  "background": {
    "scripts": [
      "js/background.js"
    ]
  },

  "update_url": "https://www.endlessm.com"
}

```

With that, I pack & sign the extension into a .crx file and, install it in the system, and I can see how both Chromium and Chrome load the policy in chrome://policy and recognize the extension in chrome://extensions, but it remains disabled.

Any extra hint? I have the feeling that I'm missing something obvious, but I'm not sure what...

> See https://developer.chrome.com/apps/autoupdate for more information.

Yes, I saw that before, but I will give it another look.

Thanks!

Oh! I answered myself by re-reading that document and experimenting a bit more...

Turns out that I actually need to have a valid XML file pointed by the update_url field in the policy.json file for the extension to be enabled when using Group Policies! Creating a file with the following contents:
```
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='fpmnjlkappdkncfmjefheaidpmbmfdfk'>
    <updatecheck codebase='file:///usr/share/eos-exploration-center/eos-exploration-center.crx' version='1.0.1513599758'/>
  </app>
</gupdate>
```

...and placing it in some random place for now (for experimentation purposes) such as /tmp/update.xml, then making the update_url in field (after the `;`) in the policy.json file point to `file:///tmp/update.xml` makes Chromium 63 load the extension as per the policy, and finally also enable it!

Now, and I understand this is actually because of  issue 794219 , that's not enough to get it working on Chrome 63, but adding an extra `"update_url": "file:///tmp/update.xml"` field to the manifest.json works that around, as suggested.

I understand this (requiring a valid update.xml document at the endpoint of the update URL) before enabling the extension is the expected behaviour, right? Reason I ask is not because I consider it a bug, but because I'd swear this was not the case a few releases ago, although I'm not 100% certain in any case.

Either way, I believe this would fix the situation for us, so thanks.

PS: I know it might sound weird to define an update URL pointing to a local URI, but our OS is a bit peculiar in that the root filesystem is read-only and managed by OSTree, which updates the OS, the browser and the extension in lock step, so that's why this makes sense in our case but YMMV.

Hi Mario. Glad you were able to make it work; the XML file gave me trouble as well last Friday. 

> I understand this (requiring a valid update.xml document at the endpoint of the update URL) before enabling the extension is the expected behaviour, right? Reason I ask is not because I consider it a bug, but because I'd swear this was not the case a few releases ago, although I'm not 100% certain in any case.

To the best of my knowledge, the update URL in the policy.json file (or the Windows registry) has always been required to make policy installs work. Otherwise, when a new profile is created, Chrome doesn't know where to get the CRX and install the extension.

> To the best of my knowledge, the update URL in the policy.json file (or the Windows registry) has always been required to make policy installs work. Otherwise, when a new profile is created, Chrome doesn't know where to get the CRX and install the extension.

FWIW, I did some local archaelogy and I think not having a xml file worked at some point between Chromium 43 and 55, since that's when we used the Group policy for the last time, but I can't really pinpoint when exactly. In any case, I think this should work for us since, as I mentioned, we update everything in lock step in our particular scenario.

Many thanks anyway, I'll make sure to report here if I find any other weirdness.