Https-everywhere: Extension is broken/corrupted and won't repair on Chrome

[faried]

I see the problem both on Mac OS 10.11.6 with Chrome 54.0.2810.2 and on Ubuntu 14.04. The fact that it "broke" and I didn't notice it immediately seems like comp.risks fodder.

[auyongcheemeng]

Ditto on the the problem on Chrome 54.0.2810.2 (64 bit) on Win10.

[Hainish]

I can reproduce this, looks like it's fairly platform-independent, happening with Chrome 54 across the board. @semenko any idea what may be going on here?

[semenko]

Hm, IIRC that failure results when a local checksum/signature of the extension contents doesn't match the signature of what was submitted to the Chrome app store. (The intent is to prevent malware from modifying extension scripts.)

I've yet to see this personally -- and I don't have a great idea of what could be causing it.

If this weren't platform independent, I'd guess some client-side antivirus was rewriting / removing some of our package data [e.g. for a "suspicious" url].

[Hainish]

Thanks @semenko. Looks like this is happening with our Privacy Badger extension on Chrome 54 as well. This may be some extra contents that are packaged but not checked on either the client-side or Chrome Web Store side. I'll have to consider how to debug this, though - seems tricky, and I don't see any debugging output. I wonder if we have contacts at CWS that can help?

[semenko]

Very odd -- maybe there's a strange character encoding / odd file making it's way in, and that's hitting an edge case in Chrome?

I don't see this in 54.0.2816.0 (Ubuntu). And I don't see any similar bugs at https://crbug.com/

[Hainish]

cc @cooperq - is there a similar issue for Privacy Badger you can link to?

[faried]

I'm not sure what caused it, but it seems fixed now. Maybe a transient issue with Chrome dev? I'm on 54.0.2816.4 on OS X and 54.0.2816.0 on Linux now.

I ran into the Privacy Badger issue on Linux at the same time, but not on OS X.

[Hainish]

@faried I'm still seeing it on Ubuntu w/ Chrome 54.0.2816.0 (64-bit)

[Hainish]

In 54.0.2824.0 dev-m (64-bit) on Windows 10, HTTPSE successfully installs.

I'm still getting a failure to install for 54.0.2824.0 dev (64-bit) on Ubuntu.

[cooperq]

Relevant privacy badger issue: https://github.com/EFForg/privacybadgerchrome/issues/843

[semenko]

My instinct is that this is an edge case / error with the custom key/signing process, which isn't used very commonly with extensions.

(the 'key' parameter in manifest.json / https://developer.chrome.com/extensions/packaging )

[cooperq]

@semenko this is my instinct as well. I suspect we should talk to someone at google about this.

[Hainish]

If this issue is disappearing from a point upgrade, as reported above, they may well know about it and have fixed it already. I wouldn't count on it, though - I still see it for the latest Linux Chrome dev 54.0.2824.0. I'm with @semenko and @cooperq on this, probably best to find someone on the Chrome side to help us debug this.

[cooperq]

For me it has been around for a while, so I doubt it will go away on a point upgrade.

[faried]

It worked for a couple of weeks for me, but today I noticed that with 54.0.2837.0 dev (on OS X), it's broken again.

[cooperq]

We have a fix for this now which will be in the next release. For now
you can go to chrome://flags and find the setting for 'extension content
verification' and change it from 'enforce strict' to 'enforce'. You then
can uninstall and reinstall the extension and it should be fixed. Once
the fix is released you should be able to change it back.

[jeremyn]

Just a note: I separately reproduced with this @jmauss in issue #6696 using Chrome version 53.0.2785.89 m (64-bit) on Windows 10.

[Hainish]

Duplicating the comment from that thread:

This should be fixed as of d45ccb1, but we'll have to do a release to make sure the fix worked. I'll try to make a release today. If I'm not able to make a release, I'll have to hold off until Monday

[jeremyn]

Also to @cooperq 's comment: I can't get the extension to work/not show corrupted using any of the four options for the Extension Content Verification flag, reinstalling the extension after each change, so that's not a good workaround for me. (I can wait, I'm just reporting my findings.)

[Hainish]

Can anyone confirm this error is gone in 2016.9.1?

On August 31, 2016 2:48:09 PM PDT, Cooper Quintin [email protected] wrote:

This will be fixed by the next release

You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub:
https://github.com/EFForg/https-everywhere/issues/5874#issuecomment-243913130

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[faried]

2016.9.1 works for me on 54.0.2840.8 dev (OS X). I had to uninstall and reinstall the extension -- updating to 2016.9.1 didn't work.

[fuglede]

The issue has also been rereported on the mailing list.

[jeremyn]

Still broken for me, even after uninstalling/reinstalling.

[Hainish]

What a heisenbug - at first I was getting it consistently with chrome-dev on Windows 10, now I can't seem to reproduce it :anger:

[faried]

Tried it on my home desktop (Ubuntu 14.04, Chrome 54.0.2840.8), and both HTTPS Everywhere and Privacy Badger are marked corrupted. Reinstalling doesn't help. This is bizarre.

[CirnoT]

I can confirm this issue hit me on Chrome Stable 53.0.2785.89 m, Windows 10 Pro x64. Restarting Chrome fixed the issue for now. The issue showed up by itself after i woke up - Chrome was opened all night.

[Hainish]

I've opened a bug report with Chrome, but apparently since I marked it as a security issue it is not publicly viewable (otherwise I would link to it here)

[Lloth]

Same issue here - recently upgrading to
53.0.2785.89 m (64-bit) - Oddly the plugin was for sure working yesterday. Perhaps related to the recent plugin update? (Version: 2016.9.1)

Also effecting 55.0.2846.4 canary (64-bit)
Reinstalled from store and repair and both have the same issue.

Disabling the hash enforcement DOES work.

[jeremyn]

@Hainish I tagged this High Priority, maybe it'll jump out at people looking to report it and we can prevent some duplicate issues.

[Hainish]

Thanks @jeremyn

[jeremyn]

@Hainish Sure. You could also add a note to https://www.eff.org/https-everywhere if you think that's appropriate.

[funkydude]

Chrome 53 is now released and this is broken for everyone. The title should be renamed to remove the mention of "dev". You might also want to get on fixing this since the extension has now been rendered useless for all Chrome users.

[jeremyn]

@funkydude I've updated the issue title. I agree this is serious. @Hainish opened a bug with Chrome yesterday (see this comment).

[Deadroom]

I had to clean Chrome cache, disable all extensions and add one by one again to make sure none of them were breaking it.
When i reinstalled the extension it gave me no problem anymore.
Using Chrome 53.0.2785.92 (64-bit) on Linux.

[war59312]

I was able to fix it by visiting the extensions page on the chrome web store - there was a message at the top of the screen saying the extension was disabled and there was a link to re-enable it.

I found that this was also happened with HTTPS Everywhere.

Confirmed. Same workaround as thrnz above. Thanks. And indeed works with Privacy Badger too.

Even on Chrome Dev. See related: https://github.com/EFForg/privacybadgerchrome/issues/911

[jeremyn]

I can also confirm the fix. To be super specific, you need to:

1. install the 2016.9.1 update, and
2. go to the HTTPS Everywhere page in the Chrome Web Store, and
3. click the Enable link you see appear in a orange/yellow bar at the top of the page.

I guess there is some problem in Chrome where once the extension is disabled as corrupted, you have to manually re-enable it, even if you fix the corrupted extension. It'll be interesting to hear from the Chrome team.

EDIT: thanks to @thrnz for finding the fix, and @war59312 for linking it here.

[fuzzyroddis]

Occurring on Version 53.0.2785.89 (64-bit) on OS X with no AV

chrome://extensions/ gives me the option to repair but I haven't tried it.

Privacy Badger hasn't been affected, yet. Even though I've pressed update extensions.

[fuzzyroddis]

@Hainish could you link the issue in here?

[ghost]

For all those having issues with the latest version showing as corrupt, try these steps:

1. Install extension.
2. Once it shows "This extension may have been corrupted", go back to the Chrome store and open up this extension's page (https://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp).
3. The top of the page will have this text -- "This item has been disabled in Chrome. Enable this item". Click it.
4. Extension will get activated!
   See this :

[anand-bhat]

I've posted similar instructions in the Chrome webstore earlier today as I saw quite a few reports there.

[jeremyn]

Good idea @anand-bhat , thanks!

[lucaspetter]

This issue is showing up for me on one computer that has Chrome 53.0.2785.89, but not on another computer with 52.0.2743.116.

I tried @jeremyn's and @ChamZank's fix but it still doesn't work. When I click "Enable this item" on the Chrome web store, the HTTPSE icon briefly appears in the browser toolbar, but it disappears a second or two later. The Chrome web store page reloads and still says "This item has been disabled in Chrome. Enable this item." Also, in chrome://extensions/, it still says "This extension may have been corrupted." Clicking "Enable this item" again produces the same results.

[Hainish]

@fuzzyroddis as I've stated above, it won't do you any good, since the issue is only visible to the Chromium security team. But here it is: https://bugs.chromium.org/p/chromium/issues/detail?id=643814

[jeremyn]

@lucaspetter Previous reports are that the problem appears with the 53.0.2785.89 stable version of Chrome, so it makes sense that that's where you started to see it. Can you confirm that you are using the 2016.9.1 version of the extension? If necessary, uninstall and reinstall the extension to be sure.

[lucaspetter]

@jeremyn Yes, both computers have version 2016.9.1. I tried uninstalling and re-installing HTTPSE, as well as restarting Chrome and then re-installing, but the issue still remains.

[fuzzyroddis]

@Hainish Thanks, there is a public issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=643931

Chrome's team marked it as WontFix... _sigh_

I wonder if their version number checking is buggy?

[Hainish]

This has been acknowledged by the Chrome security team as a bug on their end in the way that Chrome does Extension Content Verification when extensions are signed with special security measures in place, as we have for our EFF extensions. Chrome is currently working on a fix to this, which involves both their Web Store and the core Chromium codebase.

They are also looking into ways in which users will have HTTPS Everywhere re-enabled automatically if it has been disabled by Extension Content Verification.

We are working with their team in ensuring that the fixes are released as quickly as possible, and will keep you informed as we make progress on this issue.

[lucaspetter]

@Hainish

... when extensions are signed with special security measures in place, as we have for our EFF extensions.

What are these special security measures regarding extension signatures? Can you discuss them while the Chromium security issue is still open?

Thanks for keeping us updated!

[Hainish]

@lucaspetter we don't want Google to have a copy of the private key that we use to sign our extensions. Usually, when you create an extension with the Web Store, it assigns a private key to you. That would make it so that Google could, hypothetically, publish malicious update to our extensions. To avoid this problem, we've generated a private key ourselves, and have a signing process that differs from most extensions. We sign the extension with our own private key before uploading it to the Web Store, which is then able to publish it.

[fuglede]

I understand where you are coming from, but really, as long as we are speaking Chrome and the Web Store specifically, they can publish malicious updates if they want to; I doubt that anybody is checking the signatures by hand (if that's even possible?)

[jeremyn]

If the EFF relied on a key that Google had access to and Google decided to make a malicious update, how could the EFF prove that it didn't come from the EFF? It would more difficult at least than if EFF just used its own key that Google didn't have.

[fuglede]

Apologies for the reiteration, but again, I doubt that anybody checks the signatures, so insofar that we are only concerned about Google's hypothetical ability to push malware, nothing much changes.

[Hainish]

@fuglede In fact they could not publish a malicious update currently. The extension ID is based on the public key of the keypair, which is generated alongside the private key. Updates will not propagate to browsers if they are not signed with our private key. If they could, then Google could indeed just make malicious updates and push them out to all browsers without our consent. This has nothing to do with any manual auditing process by users.

[fuglede]

Yeah, that's what I had in mind; they already have full control of the underlying the browser.

[jeremyn]

If there is one extension in the world that people are auditing for security reasons, it's probably this one.

[Hainish]

Modifying an extension to include malware is a completely different security scope than deploying a signed version of Chrome which intentionally ignores the signature of an extension.

[Hainish]

For one, the first is presumably a lot less detectable. Just saying "both ends are controlled by Google" isn't quite enough for me to take a security nihilistic approach to extension signing

[jeremyn]

If Google seriously wanted to be malicious, they don't have to do anything with the extension. They could just hard-code whatever evil behavior they wanted to directly in the browser itself and leave the extension untouched and signed by the EFF's private key.

Google can't be fought directly, especially in their own ecosystem. The goal is to force Google to be embarrassingly deliberate if they want to be malicious. If the EFF uses Google's key then if Google releases a malicious version of the extension, it's Google's word against the EFF's and Google has a much bigger voice. But if Google maliciously updates the browser then that would look much worse for them if it were discovered.

[lucaspetter]

@Hainish Thanks for clarifying your signature security measures. When you say you sign the extension with your own private key before uploading it to the Web Store, do you mean you use Chrome's "Pack extension" tool in chrome://extensions to generate a key (or select your existing key) and sign the extension, then upload the resulting signed/packed extension to the Web Store? Or do you have a different process for generating a key and signing the extension yourself? I'm curious because I'm making my first Chrome extension to be released in the near future, and would like to have control of the private key in the same way.

[BehnamMabodi]

@jeremyn Looks a bit like a conspiracy theory! :)
However , it's better to be safe than sorry.

[jeremyn]

I think it's extremely unlikely Google would actually maliciously tamper with the extension or do something specifically to counter it in their browser. But yeah, better safe than sorry. Anyway, the EFF needs to set a good example, and in this case it apparently helped Google identify a security-related problem, so it's a win for everyone.

[Hainish]

For the record, I'm not particularly concerned with Google itself, but its extension distribution team would be an ample target for attackers. And we've seen before compromises of points of software distribution and development.

[Hainish]

This bug has been fixed in the Chromium codebase. This fix should be deployed upon the next stable release.

https://chromium.googlesource.com/chromium/src.git/+/e4de9f973eae513486d2912e1793e943fce70014

[jeremyn]

Wow that looks non-trivial. Hurray for the Chromium team!

@Hainish Where does verified_contents.json come from for special extensions like HTTPS Everywhere? Does Google generate it themselves against an uploaded .crx using, I guess, EFF's public key?

[Hainish]

@jeremyn it is my understanding that Google usually generates it for most extensions upon them uploading the extension .zip file, and it is included in the extension download. Since Google does not have our private key and thus cannot add files to our extension, there is a backup mechanism for a verified_contents.json fetch, which relies on downloading it remotely from the Chrome Web Store. The backup mechanism, it seems, was itself broken, and that's what caused this issue. (This is what I gather from the commit message.)

[lucaspetter]

@Hainish Glad to hear it's fixed!

Can any extension developer retain sole control of the private key like this or does EFF have a special agreement with Chrome? I'm about to publish my own extension soon and would like to handle the key in the same way, if possible. (See my earlier question above.)

[Hainish]

@lucaspetter I believe Chrome made a special provision for us to be able to do this. I'm not sure that this is a feature that they support generally.

[jeremyn]

@Hainish I'm more wondering how verified_contents.json is actually created. If the problem here is that they can't create it initially because they don't have EFF's private key, then what are they using instead of EFF's private key to create it afterwards? Probably their own private key, actually, not EFF's public key.

By the way, if anyone from the Chromium team is reading this: I guess you can change this bug from 2014 from archived to closed: https://bugs.chromium.org/p/chromium/issues/detail?id=375481

[Hainish]

@jeremyn the problem is not that they couldn't create it because they didn't have EFF's private key. They could generate it just fine. The problem, as far as I understand it, is that since our extension is signed with our private key, they can't drop it into the .crx file that is delivered to users browsers. If they did, the signature would be invalid. In this case, they rely on a backup process that downloads that json file directly from the Chrome Web Store. It is that backup process which was apparently broken.

[jeremyn]

Oh okay, that makes sense. Thanks.

[lucaspetter]

@Hainish Ah, too bad. It's a shame that regular extensions are limited in how securely they can be signed. Thanks for the info, though.

[fuzzyroddis]

Just a heads up 2016.9.21 still gives:
This extension may have been corrupted.

[CirnoT]

Confirmed on "53.0.2785.116 m". Removing extension, restarting Chrome and then installing it and clicking Repair fixed it again.

[kuoirad]

I just ran into this problem this morning when I got to work.

Chrome 53.0.2785.116 m on Windows 10.

Tried both the workarounds from ChamZank 16 days ago and the one from eider-i128 just above me. No dice.

I'd be happy to help if testing and/or logs are needed.

[jeremyn]

My experience: I updated the extension using the Developer Mode "Update Extensions Now" button, though it took some tries to actually make the update happen. I then got the "corrupted" message, but was able to re-enable the extension in the Chrome web store by clicking the "Re-enable this item" link. So it works now but I had to manually re-enable it.

@kuoirad When you tried @ChamZank 's solution, did you see the yellow bar with the "Re-enable this item" link? What happened when you clicked the link?

[kuoirad]

@jeremyn - yes, I had the yellow bar. What had been happening is that the yellow bar just came back. I went to try it again to make sure I was telling you the right thing, and this time it worked. Yay Murphy.

[MechMK1]

The extension is still broken on "53.0.2785.116 (Official Build) m (32-bit)" in Windows 7 64-bit.

as @eider-i128 Commented, removing, restarting, installing and repairing did NOT fix this for me. The installation remains broken.

[anand-bhat]

The fix for Chrome is planned for v54. I believe any new versions of HTTPSEverywhere and Privacy Badger will continue to run into this issue until Chrome v54 is release.

[faried]

I ran into this today with 2016.9.21 on Mac OS 10.11.6, Chrome 55.0.2859.0 (dev). I repaired the extension (didn't work) and then reenabled it from the Chrome store.

[Hainish]

I can confirm that this issue will be fixed in Chrome 54, and Chrome has assured me that everyone who has had their extension disabled due to this issue will have it auto-reenabled.

[dhowe]

Same issue

OSX 10.10.5, Chrome v53

[AandersonL]

Today I got the same problem, strange is that I was usually using these days (this only occurred in google chrome) using Linux.

version 9.21.2016

[jeremyn]

For anyone reporting this problem with 2016.9.21: please follow the steps in https://github.com/EFForg/https-everywhere/issues/5874#issuecomment-244636812 . If the extension still doesn't work after following those instructions, please let us know exactly where the instructions went wrong for you.

[AandersonL]

thank you @jeremyn , had already followed before and fixed it all my other systems, you have any idea what this is? very strange, this happened in all my systems with google chrome!

[strykenKN]

How I disabled your Chrome security extensions

https://labs.detectify.com/2015/07/28/how-i-disabled-your-chrome-security-extensions/

[AandersonL]

@strykenKN I believe that this vulnerability has already been fixed, that's another thing

[jeremyn]

@andersonpy : to answer https://github.com/EFForg/https-everywhere/issues/5874#issuecomment-249952945 , I don't know why earlier fix isn't working for you. Maybe try completely deleting, reinstalling, and re-enabling the extension?

[AandersonL]

@jeremyn i think my english has failed haha, i already fixed that using that method in all my devices, but i still want know what happening with the browser

[jeremyn]

@andersonpy Oh okay, great. @Hainish mentioned a Chromium bug in https://github.com/EFForg/https-everywhere/issues/5874#issuecomment-247482190 , so you can read the description there and the following comments in this discussion. I hope that answers your question about what was wrong in Chrome/Chromium.

[AandersonL]

thanks @jeremyn

[lucaspetter]

An update to Chrome stable was released today (53.0.2785.143), however it looks like the patch was not included in it, so it seems stable will get it in v54. Beta and dev channels already have the patch, though.

[AandersonL]

i got something strange, i can't watch any movie on netflix because a get a error "M7111-1931-404" i see it can be a extension of my browser, so a turn off "https everywhere" then it works! so i enable again and dont work (netflix) i deleted my cache of google-chrome and still dont work with httpseverywhere enabled, then after some minutes back to work! so strange! o.O

[mnordhoff]

@andersonpy For how long? Netflix has actually been experiencing some issues today.

[jeremyn]

@andersonpy If the HTTPS Everywhere extension is installed, not corrupted, and enabled in Chrome, then please create a new issue for your problem with Netflix.

[kirk-out]

I followed #5874 (comment) and the HTTPS Everywhere extension still reports as corrupted. I'm using Chrome Version 53.0.2785.143 m (64-bit). When I click repair in my list of extensions, it goes through the repair,, the icon flashes for a moment, and then is gone, and it still says "This extension may have been corrupted." I am not a programmer, just a fairly experienced tech person.

[jeremyn]

What happens with you click "Re-enable this item" in the web store?

[kirk-out]

It goes through gyrations, the S icon appears for a moment at the
top but disappears, and then the "This item has been disabled in
Chrome. Enable this item" reappears.

[TomRoche]

summary: I can now enable HTTPSE 2016.9.21 on

$ date
Thu Oct  6 10:33:07 MST 2016
$ uname -rsv
Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02)
$ lsb_release -ds
LMDE 2 Betsy
$ cat /etc/debian_version
8.5
$ gcc --version | head -n 1
gcc (Debian 4.9.2-10) 4.9.2
$ google-chrome-stable --version
Google Chrome 53.0.2785.92

procedure:

0. start Chrome. chrome://extensions shows 2:

• Google Docs 0.9 ID=aohghmighlieiainnegkcijnfilokake
• Google Docs Offline 1.4 ID=ghbmnnjooekpmoecnnnilnnbdlolhkhi

1. browse to https://www.eff.org/https-everywhere . click icon/link='Install in Chrome' -> https://chrome.google.com/webstore/detail/gcbommkclmclpchllfjekcdonpmejbdp

2. in Chrome Web Store, click button='ADD TO CHROME', then popup confirmation button

3. HTTPSE appears to install, but when I goto chrome://extensions/ I see

HTTPS Everywhere 2016.9.21
This extension may have been corrupted

4. click link=Details . In popup, click link='View in store' -> https://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp?utm_source=chrome-app-launcher-info-dialog

5. in Chrome Web Store, click link='Enable this item'

6. toolbar button='S' now visible, and chrome://extensions/ shows HTTPS Everywhere 2016.9.21 Enabled

[jeremyn]

@TomRoche I'm glad it's working for you now. Your steps seem more or less like what's described in https://github.com/EFForg/https-everywhere/issues/5874#issuecomment-244636812 .

[TomRoche]

@jeremyn: except that "what's described in https://github.com/EFForg/https-everywhere/issues/5874#issuecomment-244636812" lacks meaningful detail. Writing good doc takes effort and skill: youse should really work on that.

[kirk-out]

@TomRoche I had tried, and tried, and tried, the solution you proposed. And I tried again after your suggestion--and it worked. I don't know what's different, other than the vibes of your effort to help. I don't _think_ I did anything different, but problem solved. Thank you, too, @jeremyn

[MechMK1]

I have tried repairing the extension on version 53.0.2785.143 (Official Build) m (32-bit), which worked fine. The extension does it's job now. However, I had to manually repair the item. It did not re-enable automatically as said above

[Hainish]

Just FYI: https://www.chromium.org/developers/calendar puts the release of Chrome 54, which fixes this issue, at stable at October 18th. I think we should close the issue at that point, after verifying the fix works as intended.

[terrorist96]

Chrome 54 has been pushed. I can confirm that the issue is fixed for me. This can be closed.

[jurgenhaas]

Confirmed. Just needs one more "Repair" in the extension list and then it's working fine.

[Hainish]

I had to click "Repair" twice on Chrome 54.0.2840.59 (64-bit), Debian 8, HTTPSE 2016.9.21 before it was actually repaired.

According to the fix description:

This patch fixes the bugs and also introduces a change which clears the
corruption "disable reason" on extension autoupdate, so that users who
had the extension disabled because of this bug can get it re-enabled
automatically by an extension autoupdate.

I have yet to test this, I'm not sure what the frequency of autoupdate on chrome is, or if the extension actually has to cut a new release for this to work.

I've also confirmed that new installations of HTTPS Everywhere are not disabled.

This issue should be considered fixed as of Chrome 54. Closing.

[ryan-copperleaf]

Still broken for me on Chrome 54.0.2840.59, HTTPS Everywhere 2016.9.21, no matter how many times “Repair” is clicked. Using the AUR google-chrome package, if that matters.

[Hainish]

@ryan-copperleaf does uninstalling and reinstalling the extension work? This is not a proposed solution, but I'm curious.

[SylveonBottle]

@Hainish Getting the same issue as everybody else, maybe I can provide requested details.

Just upgraded Google Chrome, noticed that the HTTS-Everywhere extension was "disabled."
This is listed in Extensions:

HTTPS Everywhere 2016.9.21 Repair
This extension may have been corrupted.

Clicking "Repair" pops up a window asking if you'd like to repair the item, with Cancel or Repair extension as the options. Clicking Repair extension causes HTTPS Everywhere to dissapear for a second from my Extensions list, then reappear as it should (no errors, options to enable it when in private mode, etc). About 100 milliseconds after reappearing, it turns gray and claims that the extension is corrupted again.

Other than simply clicking Repair, I have also taken other actions. Uninstalling the extension, closing chrome, re-opening it, then re-installing HTTPS Everywhere from the Chrome Store causes no change in the error.

Some users have wrote a review in the Chrome Store claiming that installing the extension, then refreshing the chrome store will give you an option that says "This item has been disabled in Chrome. Enable this item". Some users reported that clicking Enable this item fixes the extension for them. I'm assuming that it forces Chrome to use the extension regardless of whether it's corrupted or not.
The problem is, this doesn't work for me. Clicking "Enable this item" simply refreshes the page and gives me the same option. I'm assuming it does something other than _just_ refresh the page, of course.

If you need any more information/documentation, just ask. If you are unable to reproduce the error yourself, I'll even be willing to let you remote-control into my desktop to fiddle around with testing it. Anything to get this wonderful extension back in operation.

A side note: This extension works perfectly in the latest version of Chromium.

[ryan-copperleaf]

@Hainish Reinstalling doesn’t work, no.

[Hainish]

Reopening issue while we debug the issue with @ryan-copperleaf's installation

@SylveonBottle what version of Chrome are you using?

[SylveonBottle]

@Hainish Sorry for the delay, need to work on my email notifications.

Google Chrome 54.0.2840.59

[ryan-copperleaf]

I just had an installation succeed after trying again (with a “corrupt” instance already there). That action and situation aren’t new, though.

[Hainish]

@SylveonBottle All good - what OS are you using? I'm wondering if this is specific to a given platform.

[SylveonBottle]

@Hainish Again, sorry for the delay. Went to bed.

Using Manjaro 16.08 with a Xfce desktop, 64-bit and 4.8.1-1 kernal.

Do consider the fact that there are many negative reviews on the Google Store concerning this issue.

[Hainish]

Interesting, so Manjaro is based on Arch, and @ryan-copperleaf is using an AUR (Arch) google-chrome as well.

This indicates to me that this is a problem with the Arch release of Chrome 54.

[Hainish]

@SylveonBottle can you try the solution @ryan-copperleaf used?

I just had an installation succeed after trying again (with a “corrupt” instance already there). That action and situation aren’t new, though.

[SylveonBottle]

I reformated my computer and installed the KDE version of Manjaro (previously using the Xfce version)...
for some reason I can now install the extension.

Sorry, but since I'm now unable to reproduce the corrupt-extension bug, I'll no longer be of use. If you have any other questions about my new operating system, though, feel free to ask.

@Hainish

[Hainish]

I'm closing this again since those who had ongoing issues are now reporting the problem fixed

[gloomy-ghost]

There is another report: #7456

[Pysis868]

Just had the issue today (11/10/2016). Will check this new thread in #7456 in case it is a different root cause.

[Hainish]

@Pysis868 what version of the extension are you using?

On November 10, 2016 11:37:24 AM PST, Pysis868 [email protected] wrote:

Just had the issue today (11/10/2016). Will check this new thread in

7456 in case it is a different root cause.

You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
https://github.com/EFForg/https-everywhere/issues/5874#issuecomment-259786241

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Pysis868]

I'm posting my info in the other thread #7456 that is more recent and may more closely apply to the cause for my problem than this one, if that is fine.

[mezmi]

Still experiencing this issue on Chrome 55 (64bit) / Ubuntu 16. Privacy Badger fails to work properly either, both "corrupt" immediately after installation.

[Swimmer63]

Same here. This is a problem as of today.

[KaneHart]

Same issue here. Version 55.0.2883.87 m

[KaneHart]

@Hainish Please reopen.

[Hainish]

@KaneHart this issue is tracking current "extension corrupted" reports: https://github.com/EFForg/https-everywhere/issues/7456

[dglezschez]

Updated Chrome today, still having the issue with HTTPSE
Neither option given here (reinstall, restart, enable, Repair...) works. Windows 7 32bit

[iainbryden]

I also have "extension may be corrupted" errors. Two laptops, Windows 7, Chrome, version 2016.12.19

[Hainish]

This issue is tracking current "extension corrupted" reports: #7456. Please issue reports there. Locking conversation.