"Keeping a consistent extension ID" without "key" in manifestv3

[DeCastro]

Several months ago I started working on a chrome extension which 

employs Oauth2 which I need because my extension interacts with 

both Google Drive and ExtensionPay.

After much thrashing around with systems I ill understood, I 

finally got a consistent extension ID. I got a corresponding .crx file, 

a .pem file and a "key" in my manifest. Now my extension is working 

just fine and whenever/wherever I install it (in developer mode) the 

extension id is always the same.

But now when I try and upload it to the store it tells me that "key" is 

not allowed in the manifest and when I remove the key then the 

store shows a different ID. I had thought that the crx and pem files 

somehow dictate the ID you end up with but maybe that's wrong?

Maybe I need to put the crx/pem in a special location? Or upload 

them somewhere?

This page: https://developer.chrome.com/docs/extensions/mv3/manifest/key/ purports to 

give instructions on how to keep a consistent ID but the Public Key 

it displays (starting MIIBIjAN...) is different to the one I've been using 

(which starts MIIEvgIBA...) so I assume that will result in a different ID.

Any ideas?

[Simeon Vincent]

The public key shown in the screenshot on that page (beginning with MIIBIjANbgj…) is purely for illustration purposes. If you somehow had the same public ID when you uploaded your extension to CWS, well, then there would be two extensions with the same ID, which isn't possible.

You mentioned that CWS complains about your extension having a key when you try to upload it. The solution is pretty direct: delete the "key" from the manifest when you upload. If your extension already has a build process, you should be able to automate this process by adding a step to strip the key when generating the artifacts that you zip and upload to the web store.

Simeon - @dotproto

incremental.software

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/cbbfcd9d-8786-4c2c-ab9f-fdc4bba78613n%40chromium.org.

[hrg...@gmail.com]

The procedure to keep your extension ID when you upload your extension to the CWS for the first time is as follows:

1. Remove the "key" property from the manifest

2. Package your extension in a zip file

3. Add your private key file to the root directory of the zip file. The file name must be "key.pem"

4. Upload the zip file to the CWS

That's it. You don't need to repeat this procedure ever again.

[DeCastro]

I just tried following those steps, but the resulting ID is not the same as the one I've been using these past months.

[hrg...@gmail.com]

That means the "key" property you are using in your manifest does not correspond to the key.pem file you uploaded to the CWS.

In order to get the "key" property that truly correspond to your key.pem file, follow these steps:

1. Go to chrome://extensions and click on "Pack extension"

2. Enter the directory of your extension, then your key.pem file, then click on "Pack extension"

3. A new .crx file will be created, drag that file to the chrome://extensions page in order to install it

4. Take note of the extension ID you just installed. Let's call this <EXT_ID>

5. Go to chrome://version and take note of the folder path next to "Profile Path". Let's call this <PROFILE_PATH>

6. Open this file: <PROFILE_PATH>\Extensions\<EXT_ID>\<version>\manifest.json and copy the "key" property

[Cuyler Stuwe]

I've built a barebones template that I've used as a starter for a lot of the more "novel" extensions I've been asked to write, and this functionality is something I've baked into the package.json scripts. This OpenSSL-based method is a bit nicer than the manual methods you guys have been talking about, particularly since it can be automated.

Basically your problem can be one of a handful of things:

1. You aren't using the appropriate corresponding information (as hinted in the prior reply).

2. You're trying to update the information after-the-fact (you can lock the ID only on the initial upload).

3. CWS has changed its behavior since my last upload (highly unlikely).

[DeCastro]

Thank you to everyone for their suggestions so far. I think I have it all sorted now but I thought 

I would summarize own thing that may perhaps help others...

When I tried to upload my zipped extension to the "Chrome Webstore Developer 

Dashboard" as a brand new extension (i.e. not an upgrade of a previous one) using the "+ New item" button 

I got the message "key field not allowed in manifest". This really threw me because I assumed that this 

meant the "key" field was *never* allowed in the manifest. I thought perhaps this was some recently 

introduced new restriction. A more correct error message would have been "key field not allowed in 

manifest when you *first* upload to the store, but you can (and should, for a consistent extension ID) 

include a key field in all future uploads of this extension" that you do with the "Upload new package" 

button.

[hrg...@gmail.com]

but you can (and should, for a consistent extension ID) 

include a key field in all future uploads of this extension" that you do with the "Upload new package" 

button.

There's no "should", only "can". It doesn't matter if you update a package with or without the "key" property. The extension ID is decided the first time you upload the package; subsequent updates cannot ever change the extension ID, whether you include the "key" property or not.

[Michael Reiss]

R: "should/can"... I see, OK, how about this statement then.... on all subsequent 

uploads of updates to an existing extension (via the "Upload new package" button) 

a "key" field in the manifest is optional. Having it there can has the advantage that

if you want to try out subsequent experimental versions of your extension (not yet 

uploaded to the store) in developer mode, then the key ensures that the ID will 

be the same as the store version.

Is that all true?

[Michael Reiss]

R: "should/can"... I see, OK, how about this statement then.... on all subsequent 

uploads of updates to an existing extension (via the "Upload new package" button) 

a "key" field in the manifest is optional. Having it there has the advantage that

if you want to try out subsequent experimental versions of your extension (not yet 

uploaded to the store) in developer mode, then the key ensures that the ID will 

be the same as the store version.

Is that all true?

On Sun, Aug 6, 2023 at 2:40 AM hrg...@gmail.com <hrg...@gmail.com> wrote:

[Hr Gwea]

Here is a summary of all the cases:

	Local installation		CWS first upload		CWS updates
	"key" property	key.pem file	"key" property	key.pem file	"key" property	key.pem file
Can be present?	Yes	Yes	No	Yes	Yes	Yes
Determines ext. ID?	Yes	No	No	Yes	No	No

[DeCastro]

Re: table - that's really useful, thank you.