The issue only appears for a locally build extension, which will sign the extension with a local key (not from CWS).

Our extension is on CWS, but it has a different ID, as it's signed with the CWS key. There is no problem with this one.

I cannot post the exact repro steps here as the extension is part of Google internal project that has not launched yet. Feel free to ping me, and I'll walk you through the repro steps.

Some investigation notes:

Dragging crx files into the extension page no longer works in M63.

Dragging a .crx file into the extension page installs it as an "Internal" (https://cs.chromium.org/chromium/src/extensions/common/manifest.h?l=32&rcl=bacb640aa73495f6746a60ecc1789033cf80f2ae) extension whereas dragging a folder with the same extension into the extension page installs it as an "Unpacked" extension. Unpacked extensions still work in M63. 

I'm somewhat confused as to why dragging a CRX into the extension page installs it as an "Internal", auto-update-able extension. This doesn't sound like something that should have been working unless the extension was whitelisted by enterprise policy. 

Forcepoint is reporting a similar issue with their chrome extension. Unlike the example in this bug, it was not marked as "corrupted"; it was simply greyed out. 

They don’t have an in-store equivalent; their latest extension ID is penocbmdhiadkelaobnmkdnkclamopfn. Here are their manifest.json and background.html: 

manifest.json: https://drive.google.com/open?id=1MAggXsZW7LNCxJfr8KqOFmDq-4ko8FTd
background.html: https://drive.google.com/o pen?id=1xvv5uV39R0hHxLjYxMEmfn14YdOUOLMI

They tried the update_url trick and it did not solve the issue. 

The reason we needed the CRX install was that installing test builds that way would keep the extension ID constant across installs on different machines. Installing unpacked extensions is not a workaround as it generated a new extension ID on different machines.

I has seen this issue in Canary months ago on 63 but I assumed that maybe crx installs on Canary were disabled. 

I second what COmment 5 said.  We are in _exactly_ the same situation.

I second what commenter #5 said.  We are in the same situation.

Also, installing an extension using a CRX file allows for testing of our data 'sync'.

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

commit fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Fri Dec 15 02:58:12 2017

[Extensions] Update InstallVerifier::IsFromStore()

Simplify the InstallVerifier::IsFromStore() logic to omit the migration
logic. This previously said that extensions that were in any
auto-updatable location with an empty update URL were considered as
being from the store, but this is incorrect for policy-installed
extensions.

Instead, rely purely on the Extension::from_webstore() bit or the
update url pointing to the webstore.

Add unittests to verify the new behavior.

Forked from proberge's patch at:
https://chromium-review.googlesource.com/c/chromium/src/+/748775

Bug:  794219 
TBR=dtrainor@chromium.org (c/b/downloads)
TBR=zea@chromium.org (c/b/sync)

Change-Id: Ie4357238078b4c3bf2fd180c6c0099fe1f5bd90e
Reviewed-on: https://chromium-review.googlesource.com/826503
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: proberge <proberge@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524303}
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/download/download_browsertest.cc
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/extensions/extension_browsertest.cc
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/extensions/extension_browsertest.h
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/extensions/extension_service_test_base.h
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/extensions/install_verifier.cc
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/extensions/install_verifier.h
[add] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/extensions/install_verifier_unittest.cc
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/sync/test/integration/sync_test.h
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/browser/ui/webui/extensions/extension_settings_browsertest.h
[modify] https://crrev.com/fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f/chrome/test/BUILD.gn

I was able to reproduce the issue described in #4 where policy-installed extensions on the ExtensionInstallForcelist can get marked as corrupted and disabled if the extension do not contain an update-url in its manifest. 
A temporary workaround is to set an update-url in the extension's manifest.

The fix in #8 should work by making the Content Verifier stop trying to analyze such extensions. I patched in the change from #8 and verified that the extension is no longer disabled with the patch. 

FYI, this is likely something we'll need to merge to M64 and possibly even M63.  I'll let it bake over the weekend and check back next week.

cc abdulsyed@ FYI that this might be coming down the pipe.

Sounds good - adding Merge-TBD label now, to keep it on radar. But once you think it's ready for review, please add Merge-Request-64. 

I took a quick look the CL attached to this bug, but it's not clear if it actually fixes our issue.

@rdevlin.cronin, would dragging CRX files into the extension page still work? 

It's fine if they are disabled after some O(min) time. But it would completely break our testing flow if they are disabled right away. 

@sacomoto (and others who had this issue) would you be able to test the fix on today's Chrome Canary? Version 65.0.3296.0 and above should contain the fix.

evanwiedersoan@, can you please test dragging the dev CRX on Chrome canary? (Don't forget to remove the "update_url" from the manifest before testing)

Tested dragging a locally built and signed .crx  on Chrome Canary 65.0.3298.0 on Mac. It had the same behavior for when the extension manifest did and did not include the 'update_url' field; in both cases, it refused to enable the extension, saying that "The extension is not listed in the Chrome Web Store and may have been added without your knowledge"

Is this Canary specific or is this going to become standard behavior? It breaks our testing flow completely

The NextAction date has arrived: 2017-12-19

I'm running Chrome 63.0.3239.108.

Adding the update_url to the manifest file gets rid of the 'This extension may have been corrupted' error, but I'm now getting the same problem as @evanwiederspan - It refused to enable the extension, saying that "The extension is not listed in the Chrome Web Store and may have been added without your knowledge"

Hi Evan,

Thanks for the update; sorry we broke your testing flow. 

Are you able to test the extension on Linux instead of Windows or MacOSX? Alternatively, are you able to load the extension as an unpacked extension? (Load developer mode -> Load unpacked extension) for your testing purposes?

As per the policy described in https://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-from.html, Chrome is trying to protect users from malicious extensions by disabling or preventing the installation of unwanted off-store extensions. 

There was a flaw in the verification mechanism. We tried fix the flaw in M63, but the fix had some issues - it shouldn't have impacted Linux or enterprise policy-enabled extensions. Devlin's fix in #8 handles these cases. Otherwise, I believe that this change is intended and will become standard behavior. 

Hi Proberge,

When you say "I believe that this change is intended and will become standard behavior", does this mean we'll no longer be able to install and enable locally PACKED extensions?

Yes, I believe that's the case. The locally packed extension is not from the CWS.

Hi Proberge,

Why is there such a sudden change in behavior between 62 and 63? (we were able to enable locally packed extensions in 62). Where is the notification?

Hi @bnagelberg,

I must admit I wasn't aware that dragging CRX files to chrome://extensions/ was possible. I didn't think there would be any adversely affected legitimate extension developers hence did not write a notification.

Hi Proberge,

Now that you are aware that legitimate extension developers are affected, can you restore that functionality (dragging .crx extension files to chrome://extensions/)?

Hi @bnagelberg,

I can look into it, but there will most likely be some constraints. For example, we could try to restrict that functionality (dragging .crx extension files) to developer mode and disable the extension when developer mode is disabled. Note that would result in the "Disable developer mode extensions" pop-up being displayed _every single time_ you open the browser.
(See screenshot in https://stackoverflow.com/questions/23055651/disable-developer-mode-extensions-pop-up-in-chrome)

Does this seem like a reasonable compromise? 

Hi Proberge,

Yes, this seems like a reasonable compromise. Thanks.

Hi Proberge,

This is not a reasonable compromise for me for example.

I am a normal user, and all I wanted was a custom "new tab" page that did not mess with the flow of being able to start typing an URL into the address bar right away.
Recently, one of the Chrome updates broke the extension I was using, and after trying 25 others, I realized the only option was to hard code my private "new tab" page into a custom-made extension. So I created a locally packed extension just for this purpose. Just to be able to set a new tab page. (Sounds ridiculous, right?)
Once that was done, I faced the "developer mode" popup annoyance. Finally got rid of that too: https://stackoverflow.com/a/46362471/2588826
Now, my extension broke because of this issue. I found this bug report, and was able to fix it by adding a fake "update_url" pointing to this page. But as far as I understand, you're saying this will not work long term either.

What would you propose, how should I work around the issue that will arise once you disable locally added extensions?

Cheers,
Denes

Removing Merge-TBD for now. Please add Merge-Request-64 label when ready. 

Hi @pantherdd

The link you provided relating to the developer mode pop-up (https://stackoverflow.com/a/46362471/2588826) mentions the ExtensionInstallWhitelist. 

If you're using the ExtensionInstallWhitelist, I think Devlin's fix in https://bugs.chromium.org/p/chromium/issues/detail?id=794219#c8 should allow your extension to stay enabled. Could you test on Chrome Canary that it does? Thank you!

> But as far as I understand, you're saying this will not work long term either.

Policy-enabled extensions should keep on working in the long term.

proberge@, the proposal on comment#28 seems really reasonable for our use case. Another alternative is to add a new command line flag allowing dragging CRX directly into Chrome. 

As evanwiederspan@ said our testing flow depends on dragging packages extensions directly into Chrome (because we need a stable extension id).

As proberge@ mentioned, we have had a policy disallowing offstore extensions on Windows and Mac since 2015. [1]  The fact that this was previously not enforced for extensions that were dragged-and-dropped on the chrome://extensions page is a bug (and directly violates the public policy).  It's definitely unfortunate that this broke certain legitimate flows, but I don't think this is something we should backpedal on, or that we should reduce security by adding workarounds that could be abused.  There are alternate flows available, including:
- Loading as an unpacked extension
- Loading the extension through enterprise policy
- Uploading the extension to the webstore

evanwiederspan@, is there a reason that loading the extension as an unpacked extension would not work?  Regarding the stable id, specifying a "key" in your manifest will produce a stable id. [2]

pantherdd@, is there a reason not to publish the extension in the store?  If you wanted to, you can restrict who's allowed to install the extension to a certain domain/group, but really, if you find the extension useful, other people might, too. :)


[1] https://blog.chromium.org/2015/05/continuing-to-protect-chrome-users-from.html
[2] https://developer.chrome.com/apps/manifest/key

bnagelberg@: Please read the directions at https://developer.chrome.com/apps/manifest/key. (The "key" value is not supposed to be an id, but a special hash.)

Hi @bnagelberg,

According to https://developer.chrome.com/apps/manifest, it seems like the value of the "key" should be the public key of the extension. You should be able to find it in the packed extension's manifest.

I think this is something we'll want to merge to M64.  Adding label.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

To rdevlin@ and proberge@:

The only way to test the permission upgrades and issues related to that is to install via CRX. Loading the unpacked version will not pass you through the same install code path and no warning or permission popups appear and the extension is not disabled is permissions are changed. CRX install is the closest way of testing our extension before submitting it to the store. 

What is the problem with providing a command line flag and enabling the crx extension again ? 

The key field was not working at some point when implemented CRX to get the stable ID for testing. But it appears to be working now. But the install code path testing and permissions are still only possible to test via crx.

proberge@ (#31): "Could you test on Chrome Canary that it does?" I have no idea how to do that, I'm just a normal user of Chrome who is already down a lot longer rabbit hole than I should be to just set a static HTML as my new tab page. But if you say that adding the ID to the "ExtensionInstallWhitelist" will allow my private extension to keep working, I believe you. (It is still a pity that it's so over-complicated to achieve such an obvious task, but that's another topic I guess.)

rdevlin....@ (#33): "is there a reason not to publish the extension in the store?" – I think that's one of the options I tried to do earlier, as it seemed like a lot easier option than this "ExtensionInstallWhitelist" "hack", but I hit a roadblock somewhere down the line. As far as I can remember, either that I would've had to provide a credit card and pay to do be able to do that, or that I couldn't make the extension private.
"if you find the extension useful, other people might, too." – The extension consist solely of a static HTML page that replaces the generic new tab page. It contains a number of links I like to return to from time to time, so I don't think it's useful to anyone else, and I don't plan to put effort into making the page customizable/dynamic somehow; that staic HTML completely fulfills the intended purpose for me.
An extension that would allow the new tab page to be set to an arbitrary external (or file://) URL without taking focus away from the URL bar would be cool, but I think that is not possible at the moment ("chrome_url_overrides/newtab" can only be a reference to a HTML built into the extension, and redirecting from that page generates issues).

Cheers,
Denes

He there just for the information a tested already extension without update_url in manifest on Chrome Canary and it works. You need to set ExtensionInstallWhitelist register with correct extension id and the extension is working correctly.

Thanks for the thoughts, folks!

ddehghan@:
> CRX install is the closest way of testing our extension before submitting it to the store. 

Can you walk me through this flow a bit more?  How exactly do you use crx install to check permissions the permissions flow here?

> What is the problem with providing a command line flag and enabling the crx extension again ?

At a high level, this can be summed up as the problem that for every exception we allow, it's an additional exception that can a) be exploited by malware and b) lead to more bugs (with a) being the biggest concern).  Specifically in this case, command line flags are actually pretty low hanging fruit for malware - this is the reason we don't usually allow command line flags to do things like circumvent browser security, and why we need to show noisy warnings for more dangerous commandline flags. 

> The key field was not working at some point when implemented CRX to get the stable ID for testing. But it appears to be working now.

If the "key" field ever doesn't work, please file a bug.  It absolutely should. :)



pantherdd:
> I would've had to provide a credit card and pay to do be able to do that, or that I couldn't make the extension private.

You *will* have to pay a one-time $5 developer fee (which allows you to publish multiple extensions), but you should be able to restrict access to the extension.  The enterprise policy approach won't require any payment, but might require more maintenance.  The developer mode (unpacked) approach doesn't require much maintenance and requires no payment, but results in a noisy popup each start.  Unfortunately, none of these are perfect solutions for a case where you just want to have a hobby extension for personal use.  Sadly, I don't think we can easily justify relaxing the restrictions, because of the security risk it presents.  (I feel the pain, too - I see the dev mode warning bubble each start of chrome.  It would be great to fix that - and we're hoping to - but that's a separate issue.)

rdevlin....@: I agree that browser security is very important these days, and as long as I have a way to somehow force the browser to understand that my own extension is something that I do want to use, I'll accept the hurdles. It seems like "ExtensionInstallWhitelist" is a way to run my hobby extension for free, so I'm fine with that. However, that leads me to the question: why is adding an ID to the "ExtensionInstallWhitelist" secure, if everything else is not? Couldn't a malware do that just as easily behind the scenes?
Or if it is indeed secure, wouldn't it be possible to just set the same thing right from the browser, like a checkbox next to the extension "I do explicitly want to run this, but thanks for the warning"? :) I can already check the current value of that setting at "chrome://policy/", but there's no way to add/remove something to/from the list.

(The easiest solution to my specific extension would of course be a simple checkbox in Chrome's settings, saying "Load my Home Page on any new tabs that I open". Given the number of extensions aimed exactly at this, it'd be nice to have this built in. But I guess that'd be a separate feature request. Where do I file one?)

Hi rdevlin@ thanks for your answer and working late on this. I am sure people are getting ready to leave for the holidays :-)

How we test extension permissions issues:

For each build we create a crx and zip file in our build process. The zip file is for uploading to chrome store. The crx is for "installing" or adding the extension to the local machine. We usually install the publish build of our extension by dropping its CRX onto the local chrome extension page. Then we drop in the CRX extension of the build we are about to publish onto the same chrome extension page. If we had added more permission to the manifest at this point we get the warnings or popup that the user would see during the upgrade had we published this new build to the chrome store. 

Installing via unpackaged extension does not pop up any warnings and leads to a false sense of security. We have caught several times major bugs from going live by simulating the upgrade scenario via CRX install of publish build to the target rc build.

I am happy to share my screen and show you this if you like. 

Just ping me.

Thanks again for your time and I appreciate your effort of keeping the chrome platform clean and maintainable. Not installing CRX is actually a great thing. There are a bunch of shitty chrome store clones that host crx files. Killing them off would be great. 

Another developer with the exact same issue. We've had the same problems from preforming our normal testing flow described in #46.

Everything else has already been said, but two other points I'd like to mention.

We use the nativeMessaging permission so packing a new extension rather than drag and dropping .crx means the IDs won't match, and we cannot test the extension with the native application. Okay, sure, we can change the allowed_origins to include this new ID, but that's more cumbersome and more of a divergence from the flow a real user would follow (testing the update).

I understand the reasons on both sides, dropping .crx support and easier/improved testing of extensions before publication to the store. Maybe the end goal might be to include better support in the dashboard when publishing extensions? If there was something like a stable channel and a beta channel only available to the specified test users. Test users could still test the upgrade by switching to the beta channel, still using the same extension ID. And avoids the .crx issue, as it looks like most people here are objecting that they're not able to safely test their extension before uploading to the store, not objecting to uploading to the store itself. But appreciate that's not a small change and won't happen overnight.

pantherdd@:
> why is adding an ID to the "ExtensionInstallWhitelist" secure, if everything else is not? Couldn't a malware do that just as easily behind the scenes?

Great question!  The short version is that there's a lot more that's needed to set up a fake enterprise policy on a user's machine than to, e.g., add a commandline flag (adding a commandline flag you can just create a shortcut that launches chrome with the flag).  It certainly isn't perfect, but it's a much larger hurdle for malware.  proberge@ might be able to add more color there.

> Or if it is indeed secure, wouldn't it be possible to just set the same thing right from the browser, like a checkbox next to the extension "I do explicitly want to run this, but thanks for the warning"? :)

We'd definitely *like* to be able to do this, and it's possible we might be able to at some point.  At the moment, we store things like this in the Preferences file, which isn't quite secure enough (though we're working on it).  If we can resolve that, then we could also remove the developer mode warning bubble showing on startup each time (which would make that a viable solution for your use case).  I'm not sure when/if this will happen though (but I'd definitely like to see it!).

> (The easiest solution to my specific extension would of course be a simple checkbox in Chrome's settings, saying "Load my Home Page on any new tabs that I open". Given the number of extensions aimed exactly at this, it'd be nice to have this built in. But I guess that'd be a separate feature request. Where do I file one?)

crbug.com/new is the right place to file feature requests.  For our triaging, it will help if you put "Feature request" in the title.  Feel free to link the issue here if you file one, and we can discuss more there.


ddehghan@:
Okay, I see.  Yes, unfortunately, this flow *will* be broken.  At a higher level, we know that extension permission increases are a pain point, and we're working towards making it better, but it's a hard problem.  I think the best solution here would be to have a (possibly restricted) beta/test version in the store that you can try this out on before pushing it to the stable version.  I understand that this isn't ideal, since it means a much heavier-weight flow for checking permissions, but it's also the most foolproof.  In the current flow, there's not really any guarantee that the behavior will match what webstore users will see - we may decide to change how we treat drag-and-dropped crx's (perhaps to treat them more as developer/unpacked extensions, which can silently increase permissions), so there's really no guarantee that this flow would continue working long-term.

Two other tricks that you might be able to use:
- We only restrict to webstore extensions on Mac, Windows, and CrOS (not Linux).  If you have a Linux box, you could try this flow there (though note that you would need to make sure that the extension you used didn't point to the webstore, or else we'd verify the contents on disk match the contents in the store).  Similarly, we don't enforce on Chromium (vs Chrome) builds, so if you have a Chromium build you could use that.  I realize that neither of these are good solutions if you're not already set up with them.
- The logic in Chrome to determine if an extension needs to be disabled boils down to "Are there any new permission messages shown in the install dialog".  You could just install both extensions as unpacked and look at the details in chrome://extensions to see the permissions, and compare.

Note that both of these would be much better suited as a first quick-and-dirty check to weed out obvious answers - they both *might* change at some point.  The only sure-fire way to know if an extension will be disabled is to go through the webstore flow.


djhale.development@:
> We use the nativeMessaging permission so packing a new extension rather than drag and dropping .crx means the IDs won't match, and we cannot test the extension with the native application.

See https://developer.chrome.com/apps/manifest/key for instructions on how to add a "key" field to the manifest.  This will result in a stable, deterministic ID so that an unpacked extension could have the same ID as the one you use in the store.

> Maybe the end goal might be to include better support in the dashboard when publishing extensions? If there was something like a stable channel and a beta channel only available to the specified test users.

We know that this is also a pain point, and are working to make some of these flows easier for developers.  This is *technically* possible today - you can upload two different extensions, and describe one as the "beta" version.  You can also restrict distribution to certain domains/trusted users.  That flow will work, and is probably the best for deterministically checking if an extension will be disabled for users.  We hope to at some point provide better support for this to make it less clunky.



Thanks, all, for your patience here.  I understand that breaking flows like this is frustrating, and I hope that we can find solutions for all of the use cases here (though in some cases, unfortunately, it may not be as seamless).

Hi rdevlin@  OK let me walk you through the implication of what you are proposing because we are tired it today.

1) We created a new private extension and published it to a set of testers.
2) <waited 30 min for store approval>
3) uploaded the old version of the extension we are testing upgrades from.
4) <waited 20 min for store approval>
5) uploaded new version we are upgrading to
6) <waited 40 min for store approval>
7) finally now we can see the upgrade process 


Unfortunately we hit a bug. We forgot to account for the fact that the new extension now has a new ID not the old ID for the live extension that we had embedded into the code. So now we can't re-upload and test that last version. We need to build a new version 1 with higher version, then a new version 2 with even a higher version upload those to the app store and wait for approval each time to just see the pop up. !! :-( 

So work with this new publishing process we have to create a completely new build pipline with new IDs so that the IDs of the test extension will match the one in the code. That is a non trivial amount of dev work.

Also as you know just comparing permissions form the extension page between he 2 builds does not work.  Since many different permissions are mapped to the same user friendly text. But if any of those permissions are changed then the consequences are very severe. All 100s of thousands of user that we have will get their extension disabled and have to go through the extension page to re-enable it. That is just something we really want to avoid at any cost. 

Thanks, Happy holidays. 

ddehghan@:

I definitely sympathize here - this is something that we hope to improve in the future.  A few things that will hopefully help (though not by any means completely alleviate the problem):

> So work with this new publishing process we have to create a completely new build pipline with new IDs so that the IDs of the test extension will match the one in the code. That is a non trivial amount of dev work.

First off, agreed - and I'm sorry for the churn.  Once the process is in place, hopefully this will be significantly easier, though.  For instance, if stable and beta are both at version 42:
1) upgrade beta to version 43
2) check upgrade flow
(assuming nothing goes wrong in the update flow or otherwise)
3) upgrade stable to version 43

Additionally, the only times an extension has increased permissions is when the manifest changes - so things like changes to other JS files should *not* ever disable the extension.  Usually (but certainly not always!) manifest changes are relatively rare, so this shouldn't necessarily be an every-single-update process.

> Also as you know just comparing permissions form the extension page between he 2 builds does not work.  Since many different permissions are mapped to the same user friendly text. But if any of those permissions are changed then the consequences are very severe. All 100s of thousands of user that we have will get their extension disabled and have to go through the extension page to re-enable it. That is just something we really want to avoid at any cost. 

*Currently* (I can't make guarantees that this will *never* change, but we don't plan on changing it at the moment), we actually compare user-visible strings to detect permissions increases. [1] We do this exactly because some permissions map to the same user-visible text (e.g., if an extension already requires history, requiring tabs doesn't give any additional privilege), so the user would have nothing new to confirm: they've already allowed the extension access to those privileges.

Like I said, this should be a *first test* to weed out obvious problems, rather than something you rely on totally, but hopefully it would help to reduce the number of times you upload a new version as a beta that didn't include any additional permission messages, and find that it disabled the extension for testers (indeed, if you did, I'd be interested in the exact changes).  But this is not an indefinite guarantee. :/

[1] https://chromium.googlesource.com/chromium/src/+/a16ddefeb951d87636d8efd4bff0a546093a9ef4/chrome/common/extensions/permissions/chrome_permission_message_provider.cc#211

Per disucssion with rdevlin@, approving #8 for merge. branch:3282

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

commit 31266ce940cbb14be437b065f918f3cd419a23e1
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Fri Dec 22 15:24:21 2017

[M64] [Extensions] Update InstallVerifier::IsFromStore()

Simplify the InstallVerifier::IsFromStore() logic to omit the migration
logic. This previously said that extensions that were in any
auto-updatable location with an empty update URL were considered as
being from the store, but this is incorrect for policy-installed
extensions.

Instead, rely purely on the Extension::from_webstore() bit or the
update url pointing to the webstore.

Add unittests to verify the new behavior.

Forked from proberge's patch at:
https://chromium-review.googlesource.com/c/chromium/src/+/748775

Bug:  794219 
TBR=dtrainor@chromium.org (c/b/downloads), rdevlin.cronin@chromium.org, zea@chromium.org (c/b/sync)

(cherry picked from commit fe8a5cfa0e6ea00049b4de61bc7c92a858fa934f)

Change-Id: Ie4357238078b4c3bf2fd180c6c0099fe1f5bd90e
Reviewed-on: https://chromium-review.googlesource.com/826503
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: proberge <proberge@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#524303}
Reviewed-on: https://chromium-review.googlesource.com/842903
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3282@{#342}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/download/download_browsertest.cc
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/extensions/extension_browsertest.cc
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/extensions/extension_browsertest.h
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/extensions/extension_service_test_base.h
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/extensions/install_verifier.cc
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/extensions/install_verifier.h
[add] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/extensions/install_verifier_unittest.cc
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/sync/test/integration/sync_test.h
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/browser/ui/webui/extensions/extension_settings_browsertest.h
[modify] https://crrev.com/31266ce940cbb14be437b065f918f3cd419a23e1/chrome/test/BUILD.gn

Hi @rdevlin,

We're having the same problem with our admin-enforcement extension. Being able to distribute the .crx makes the process quite easy and painless. 

Would comment#28 not be a reasonable compromise (sorry, assuming one of the merges didn't already pull it in - #8 looks like it only addresses the corruption issue) over waiting for Chrome Web Store distribution or needing to use Linux specifically? 

I agree with the others and @proberge that it strikes a reasonable middle ground. The development investment also seems like significantly less effort (you all already had a working version after all - I was only ever able to install a .crx in Developer mode on MacOSX pre-63 anyway) and far more maintainable than the other alternatives proposed. It also has the benefit of easily encapsulating reasons in a single portion of the code base instead of having a custom codepath for only the Linux distro.

Given the comments here, it would seem even internal folks from Google are affected, along with all the developers in this thread:

https://productforums.google.com/forum/#!topic/chrome/kGgLwnrDKpQ

If we need to adjust our flow, we will, but it will be a painful process (we've been following the same process for 3+ years now).

I appreciate you taking the time and having the patience to address our concerns - especially during the holidays.

Thanks so much!

conor@:

> We're having the same problem with our admin-enforcement extension. Being able to distribute the .crx makes the process quite easy and painless.

The fact that admin-enforced extensions were disabled is a bug, and should be fixed in M65 (and once the merge from #53 goes in, also in M64).  Unfortunately, due to the current timing for releases, I think it's unlikely we'll be able to merge this to M63 (the current stable).

If you're still seeing this problem for policy-installed extensions, let us know.

> Would comment#28 not be a reasonable compromise (sorry, assuming one of the merges didn't already pull it in - #8 looks like it only addresses the corruption issue) over waiting for Chrome Web Store distribution or needing to use Linux specifically?

#28 would actually require a bit of work.  It would involve changing how dragging-and-dropping the extension installs the extension in Chrome, and that could also cause additional breaking changes.  Additionally, it would mean that there's very little difference between drag-and-drop vs loading unpacked.

> I agree with the others and @proberge that it strikes a reasonable middle ground. The development investment also seems like significantly less effort (you all already had a working version after all - I was only ever able to install a .crx in Developer mode on MacOSX pre-63 anyway) and far more maintainable than the other alternatives proposed. It also has the benefit of easily encapsulating reasons in a single portion of the code base instead of having a custom codepath for only the Linux distro.

It wasn't entirely working - this bug was in fact caused by fixing another bug. :) So it would be development investment either way.  Additionally, we'll likely always have the extra codepath for linux, unless we need to restrict linux to webstore-only extensions entirely.  That said, if it was clear that this was the right approach, I wouldn't object to the investment.  The larger problem is what I mentioned above - it would require changing how the installation works, and at that point, it wouldn't provide the benefits it does today, either.  And, to be clear, nothing *new* we did would make it into M63.


Can you confirm whether the admin-installed extensions through enterprise policy work properly in M64/M65?  Additionally, is there a reason that loading an unpacked extension (instead of dragging and dropping) wouldn't work for your other use cases?

Hello! I have a locally sourced extension that no longer works with V63 like most people above do. The problem is that I have no development experience and paid a developer to create the extension. Said developer is no longer available for freelance work. Is anyone willing to "fix" my extension to be compatible with Chrome 63 for a price? Please email me, thanks - JeffTfox@hotmail.com

@56: It's mentioned in the comments above, but the gist of this is that there won't be a way to just modify the extension to be compatible with this workflow.  You will need to change the way the extension is distributed (installed) to instead be through the webstore, enterprise policy, or as an unpacked extension.  Modifications to the extension itself will not solve the issue.

Does it also get blocked when installing a .crx through selenium for testing?

 Issue 801041  has been merged into this issue.

I'm getting this issue on M64 deploying extension through enterprise policy.
Extension ID: onabolffhogbbkjjhekclkagihbbfagh

Manifest HAS an update URL of:
 
update_url": "https://clients2.google.com/service/update2/crx

Hi Ryan,

Your extension is in the CWS so this sounds like a slightly different issue. Could you file a separate bug and assign it to me? Please include as much detail as you feel comfortable.

Thanks!

It seems like this bug was partially fixed for M64 onwards and that we decided to not fix the other part.

There seems to be a remaining issue with on-store extensions getting marked as corrupted for unknown reasons. The issue is tracked in https://bugs.chromium.org/p/chromium/issues/detail?id=807883.