brave-browser: [Desktop] Unable to install self-signed or third-party CRX extensions

It’s really horrendous how they say that brave “begins with giving you back power.” Please guys, listen to the community and stop making things harder for everyone

@bsclifton Are you sure that Brave is not disabling this on purpose? If I am right with my assumption that the command line switch --extensions-install-verification=enforce disables all extensions from sources other than the Chrome Web Store, then this is one of the settings you explicitly enable in one of your patches:

  // Setting these to default values in Chromium to maintain parity
  // See: ChromeContentVerifierDelegate::GetDefaultMode for ContentVerification
  // See: GetStatus in install_verifier.cc for InstallVerification
  command_line.AppendSwitchASCII(
      switches::kExtensionContentVerification,
      switches::kExtensionContentVerificationEnforceStrict);
  command_line.AppendSwitchASCII(switches::kExtensionsInstallVerification,
                                 "enforce");

Other Chromium-based browsers like Chromium (from the Debian repository), Vivaldi and Kiwi Browser don’t disable sideloaded extensions and I have only ever experienced this issue with Brave. The default startup parameter list of Vivaldi is quite a bit shorter than the one Brave uses and the extensions-install-verification switch is not part of Vivaldi’s parameter list: --new-window --flag-switches-begin --flag-switches-end --origin-trial-disabled-features=SecurePaymentConfirmation --save-page-as-mhtml

EDIT: The extensions-install-verification parameter apparently got added in Brave 0.68. So I decided to test Brave 0.67.125 against Brave 0.68.131 (both were stable releases) and I can now confirm that extension sideloading broke with Brave 0.68 when this commit got merged into the stable branch.

I was looking for a way to make a self-signed crx extension work in Brave. It looks like @aetonsi is right. I am able to get my extension working with GPO white-listing.

I’m posting this here in case others are trying to run a custom 3rd party .crx extension that’s not from the chrome webstore and getting the above error when sideloading. You need to add the following registry key(datatype are all SZ string type):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\BraveSoftware\Brave\ExtensionInstallWhitelist]
"1"="_<your .crx extension id here>_"
"2"="_<next .crx extension id here>_"
; etc...
; for example:
;"3"="npifoilcgoddgoagljbkagfmmafmphki"

Setup I tested this on, Win7 64-bit with Brave 1.3.113 Chromium: 80.0.3987.87 32-bit. This is actually Brave-portable.

Is there any work around to this problem?

Another +1 for this. Had to download Chrome again because a tool I’m using is distributed as a .crx 😢

+1 from reddit: https://www.reddit.com/r/brave_browser/comments/a542t2/just_downloaded_brave_trying_to_install_3rd_party/

OK folks - thanks for your patience on this 😄

I reviewed this issue with security/privacy folks here at Brave we agreed on the following plan:

1. The deviation from Chrome/Chromium was fixed with https://github.com/brave/brave-core/pull/8392. This was not something we intentionally did - thanks to all that helped narrow this down 😄 We should be the same as Chrome/Chromium now. The next Nightly build (1.25.x, will be available by tomorrow 8 April) will have this fix and it will propagate through the channels. It should hit Release channel on 25 May (2021).
2. Support-wise, @Brave-Matt updated our help article (you can view here) to include a link to Chromium’s documentation for Alternative extension distribution options. This is the officially supported approach for signed CRX files not in the store
3. I created a new issue for a “Brave Extension Store”, available here: https://github.com/brave/brave-browser/issues/15187. This is something we had considered in the past and would be a way to offer extensions which are not in the official Chrome Web Store. Comments extremely welcome! 😄

Given the above plan, we agreed to close this issue (offering an in-app way to bypass the security check; ex: feature flag) as wontfix. Per one of our engineers:

The downside of a feature flag is that a malicious extension could change that too since they’re both located in the profile directory. The group policy/allowlist method at least requires admin access, which a malicious extension hopefully doesn’t have otherwise you’re in deep trouble.

I know this isn’t the solution everybody wants - I championed the best I could. However, I am glad we:

• did find where we had a mistake on our side and were able to fix that (Linux w/ dev mode on should work)
• were able to update our help article to link to the official Chrome/Chromium recommended approach
• created an issue to explore a Brave store which deviates from Chrome Web Store

The reason why sideloaded, non-store extensions are blocked seems to be this flag set at compile time: --extensions-install-verification=enforce The stable and beta versions of Google Chrome seem to have a similar default setup.

Like with Google Chrome you can actually work around this restriction by creating a policy file like it is described in this tutorial from Google.

For Debian/Ubuntu users the steps are as follows:

sudo mkdir /opt/brave.com/brave/extensions
sudo editor /opt/brave.com/brave/extensions/aaaaaaaaaabbbbbbbbbbcccccccccc.json

aaaaaaaaaabbbbbbbbbbcccccccccc is the ID of your extension (you can for example retrieve it from chrome://extensions if you have sideloaded the extension already and it got disabled) This json file only needs two entries (/home/username/extension.crx is the location of your CRX file):

{
	"external_crx": "/home/username/extension.crx",
	"external_version": "1.0"
}

After creating and saving the json file, the only thing you have to do is to start Brave, visit chrome://extensions, enable “Developer Mode” and drop the extension into the browser window. Make sure that the extension is located in the path you specified in the json file. If done correctly, the extension should now stay activated.

~OK will prep a fix and create a security review to accompany, in case there was a reason for it~ 😄 ~Thanks!~

edit: looks like it was already modified to be enforce instead of strict… 🤔 This should be working…

Will review with @jumde and report back https://github.com/brave/brave-core/blob/cf8219a0571c83c5eaaac9b382189d79c2c02670/app/brave_main_delegate.cc#L166-L173

@bsclifton yes, if my understanding is correct, the current behavior was an unintentional side effect of https://github.com/brave/brave-core/pull/2471 and should be reverted to the behavior prior to 0.68.x

@bsclifton Your explanation sadly does not add up.

First of all Chromium does not block any third party extension for me. This is only a problem on brave.

The behavior you’re seeing isn’t a result of anything we at Brave are doing on purpose.

This directly contradicts Brave’s official support article, where this is explained to have been done on purpose: https://support.brave.com/hc/en-us/articles/360017914832-Why-am-I-seeing-the-message-extensions-disabled-by-Brave

Moreover my issue #10018 does not seem to trigger any interest from brave devs.

Pretty sad that brave seems to go the censoring route, just like big tech.

I used to circumvent this issue by white listing/forceinstall listing my extensions via policies in the registry (HKLM\SOFTWARE\Policies\Chromium\ExtensionInstallForcelist / HKLM\SOFTWARE\Policies\Chromium\ExtensionInstallWhitelist).

Now even that doesn’t work… Any news?

Tried with HKLM\SOFTWARE\Policies\BraveSoftware\Brave as reported here: https://github.com/brave/brave-browser/issues/5063#issuecomment-566688634 . I can confirm that my custom extension it’s working.

Quick update - I created a separate issue for how we’re not matching Chrome/Chromium on Linux: https://github.com/brave/brave-browser/issues/15024

Thanks @esjarc for helping ID the bug there 😄 That issue aside, we should be matching Chrome/Chromium and not doing anything intentional.

I have a pull request open solving the Linux issue (see https://github.com/brave/brave-core/pull/8392) which is going through security review. I also raised this overall issue (being able to install signed CRX which are not in store) with the team too - they’re going to evaluate the ask in this issue too.

We usually try to match Chromium - but this will become a larger issue when manifest v3 comes into play (which we aren’t going to do, as far as I know). Stay tuned for comments from security folks

The work-around I would recommend for now would be to use the group policy. For example on Windows, the key: [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\BraveSoftware\Brave\ExtensionInstallAllowlist] (Older versions of Chromium used ExtensionInstallWhitelist - this is now deprecated)

The registry keys won’t exist by default - you’ll have to either create those in RegEdit or double click a .reg file. For example, make a new text file, rename as extensions.reg (or similar) and putting something similar:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\BraveSoftware\Brave\ExtensionInstallAllowlist]
"1"="_<your .crx extension id here>_"
"2"="_<next .crx extension id here>_"

More info about the group policy here: https://chromeenterprise.google/policies/#ExtensionInstallAllowlist

Group policy should work on other platforms too - although I have never used it outside of Windows. Kudos to @esjarc and @shivashranz above for sharing the details 😄

I used to circumvent this issue by white listing/forceinstall listing my extensions via policies in the registry (HKLM\SOFTWARE\Policies\Chromium\ExtensionInstallForcelist / HKLM\SOFTWARE\Policies\Chromium\ExtensionInstallWhitelist).

Now even that doesn’t work… Any news?

I hope this gets fixed.

Ran into this issue after updating to the latest version of brave. As far as I can tell the only way to fix this for effected users would be to patch install_verifier.cc or extension_service.cc to remove the nonstore checks. There used to be a flag you could pass to sideload however according to google forums that no longer exists