I don't think it was suggested that the developer is at fault, but rather that there are some bugs in the verification system that can be worked around (until Chrome is fixed) by repackaging the extension.
There are two known outstanding issues:
- If the manifest refers to files with certain path formats (namely using a Unix style shortcut like '.', as in "./foo/bar.js"), verification will fail on Windows hosts and the extension can be wrongfully disabled. This is easily remedied by replacing such paths (e.g. with simply "/foo/bar.js").
- If any part of the extension refers to a resource with the wrong case (as in the CRX contains 'foo.js' but code loads it as 'Foo.js') verification will also fail. It should be noted that such extensions will normally only work on Mac and Windows anyway, so it is probably worthwhile for the extension author to address this.
If neither of these known issues apply to the extension in question, please post more details. What extension is it?
Thanks
Ken
On Monday, September 22, 2014 11:22:19 AM UTC-7, donaddon wrote:
> In what ways are false positives a "packaging issue"? Examples? It doesn't seem right that a false positive could ever be the fault of the extension developer.
>
>
> On Sun, Sep 21, 2014 at 2:02 PM, Reilly Grant <
rei...@chromium.org> wrote:
>
> Extensions are disabled automatically if changes to the extension are detected after it is installed to prevent malware from hijacking trusted extensions. If the extension has been disabled incorrectly please contact the extension author as false-positives are usually a packaging issue that is easy to resolve.
>
>
>
>
> On Sun, Sep 21, 2014 at 5:49 AM, Ozzy Ozbour <
twit...@googlemail.com> wrote:
>
>
> I have found the following message This extension may have been corrupted by malware.
> But it is not a malware! How to enable extensions and why they are disabled without any prompt?
>
>
>
>
>
>
>
>
>
>
>
>
>