Even with a fresh profile I get a Signature verification failed with this
extension:
https://chrome.google.com/extensions/detail/okmlpemfjpklknpajkaapehdglgbkgin?hl=en-us
(Chromium 5.0.306.0 on Linux)
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
Drag-N-Go does install in Google Chrome 5.0.307.9 beta.
And also on Chromium 5.0.336.0 (39849) Ubuntu!
Not using web proxy/caching.
I did get increasingly Aw-snaps or serious rendering issues in Chromium, so
I
switched back to Frefox, to discover that the excessive CPU-use has been
fixed.
That's all.
I had this problem with the Cooliris extension. Clearing the cache solved
the problem.
It seems to me like download of the extension failed partway through, but
Chrome just
tried to install the file anyway and then just falls over when it realises
the file is
broken instead of trying to re-download. Subsequent attempts to install the
extension
will result in the same error due to the partial file being cached.
http://code.google.com/p/smoothgestures-chromium/issues/detail?id=464
Clearing the cache fixes this issue. I would argue extension installs
should not be cached/install from the cache.
Comment #28 on issue 30055 by rds...@chromium.org: Signature verification
failed when installing extension.
http://code.google.com/p/chromium/issues/detail?id=30055
@asargent: I don't quite follow the reasoning--how is downloading an
extension any different than downloading any other file? You'll always get
a "more authoritative" version if you bypass the cache, but there are
enough constraints on the problem that the cache should be trustworthy. To
put it differently, it doesn't sound like the cache is the root cause;
something happened to corrupt the copy of the extension that showed up in
the cache, and we don't yet know what.
Ccing rvargas for cache related issue.
I agree with Randy; unless we're using the downloads system API
incorrectly, this problem needs to be solved at a lower level.
@asargent: I completely agree that downloading should not put the file in
the cache, and that's already on our list (I can dig up the issue # if
that's useful for you). But that change will make sure we don't *put*
things in the cache while downloading them; if they're already there
(e.g. .png already displayed where we'd doing a "save image as") we will
download them "from the cache". That would probably solve this particular
issue, just not what I consider "root cause" (which is that it sounds like
the cache is getting corrupted).
But installing user-scripts work fine. Why are scripts copied directly to
the "Extensions" directory, while packed extensions need to be decompressed
elsewhere before being copied there? Why cannot CRX files be copied to
the "Extensions" directory, unpacked there, then deleted (or even not
deleted)?