2 ms·

But if the extension ID changes, you'd need to explicitly install the new version. It wouldn't just auto-update. Then again, you say: > And since Google doesn

But if the extension ID changes, you'd need to explicitly install the new version. It wouldn't just auto-update. Then again, you say: > And since Google doesn't require each upload include the private key, then the new owner could push changes without even needing access to that key. How is this even possible that Google allows this? Is this really true? I mean, Google is such a PITA with their Webstore for the smallest possible things, but that is something they don't care about? I have three extensions which I have only released for testers, where I am the sole tester of the extensions, so that I can easily install them on my different machines without having to rsync/robocopy them and enable developer mode. This weekend Chrome decided to disable all these extensions on just one machine, because "This extension is not listed in the Chrome Web Store and possibly has been added without your knowledge". I can't override and force-enable it, when I go to the web store it says it's "inactive" and gives me the option to "activate now", but "activate now" only removes the banner and re-shows it after a reload. That Chrome profile is signed in with the whitelisted account. This happens with just one browser, my main one on my main machine, signed in with the tester account. The badge on the CWS page claims that the developer (me) has a positive balance without any strikes. I mean, I wouldn't be able to see the page if I weren't logged in with the my whitelisted email. They "care so much" but then they allow updates without the key?

chatmasta 3y ago
> How is this even possible that Google allows this? Is this really true? Yes, you only need to upload the key (meaning, include a `key.pem` in your packed zip file) on first upload. [0] However, I'm not sure if Google will allow you to upload with a _different_ key. Since that would cause the extension ID to change, I'm not sure what would happen, both to the webstore page (does the previous one 301 to the new one?) and to existing installations (do they stop auto-updating?). Incidentally, I expect this is also the reason Google allows subsequent uploads without the key. They don't want someone to lose their extension when they lose their private key. > This weekend Chrome decided to disable all these extensions on just one machine There is a trick for this, if you are loading an unpacked extension. Simply edit `manifest.json` in the unpacked extension directory, to add a `"key": "<base64 encoded public key>"`, where that public key matches the public key associated with the extension from the store. You can do this with any extension from the store, since you can extract the public key from a .crx file [1]. When you load an extension this way, the ID will be the same as the "real" extension. [0] https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Su50pbNzRms/m/VbQhXEnkAwAJ https://groups.google.com/a/chromium.org/g/chromium-extensio... (note the "You don't need to repeat this procedure ever again") [1] https://github.com/milesrichardson/crxmon/blob/4dae445b05b7641bad491834df00669764be568e/scripts/lib/extension-crypto.ts https://github.com/milesrichardson/crxmon/blob/4dae445b05b76...
- thwarted 3y ago
  Incidentally, I expect this is also the reason Google allows subsequent uploads without the key. They don't want someone to lose their extension when they lose their private key. They don't want someone to "lose their extension" if the private key is lost? That makes no sense and completely undermines using PKI in the first place. This isn't how "code signing" is supposed to work _at all_.

chatmasta 3y ago

> How is this even possible that Google allows this? Is this really true? Yes, you only need to upload the key (meaning, include a `key.pem` in your packed zip file) on first upload. [0] However, I'm not sure if Google will allow you to upload with a _different_ key. Since that would cause the extension ID to change, I'm not sure what would happen, both to the webstore page (does the previous one 301 to the new one?) and to existing installations (do they stop auto-updating?). Incidentally, I expect this is also the reason Google allows subsequent uploads without the key. They don't want someone to lose their extension when they lose their private key. > This weekend Chrome decided to disable all these extensions on just one machine There is a trick for this, if you are loading an unpacked extension. Simply edit `manifest.json` in the unpacked extension directory, to add a `"key": "<base64 encoded public key>"`, where that public key matches the public key associated with the extension from the store. You can do this with any extension from the store, since you can extract the public key from a .crx file [1]. When you load an extension this way, the ID will be the same as the "real" extension. [0] https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Su50pbNzRms/m/VbQhXEnkAwAJ https://groups.google.com/a/chromium.org/g/chromium-extensio... (note the "You don't need to repeat this procedure ever again") [1] https://github.com/milesrichardson/crxmon/blob/4dae445b05b7641bad491834df00669764be568e/scripts/lib/extension-crypto.ts https://github.com/milesrichardson/crxmon/blob/4dae445b05b76...

thwarted 3y ago
Incidentally, I expect this is also the reason Google allows subsequent uploads without the key. They don't want someone to lose their extension when they lose their private key. They don't want someone to "lose their extension" if the private key is lost? That makes no sense and completely undermines using PKI in the first place. This isn't how "code signing" is supposed to work _at all_.