"key field is not allowed in manifest."

[Z Yin]

It seems a new restriction is being added recently: if your manifest contains the "key" field, when you upload the package to the store, it'll say "key field is not allowed in manifest."

I think it's either on AB testing, or on gradual-rollout, because sometimes it's enforced, sometimes not.

Is it recently discussed in the doc somewhere? Could someone provide a link to the new doc? Thanks!

The new change will make life less convenient for some people. From my own understanding, here's why people use "key" filed in their manifest: 

Say you need the hardcoded extension url on your server to configure some CORS. But in dev mode, the extension url is randomly assigned. So what you do is put the key in the manifest, then load it in dev mode, then the url will be always the same as the real one.

[Cuyler Stuwe]

That has been the case for a while (perhaps always). I've always seen it whenever I've accidentally uploaded the wrong package.

The "key" field in the manifest represents a public key; What the CWS wants for the initial upload is the private key (as a key.pem file).

--
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/1cbbd9d1-b79a-4675-9e73-41969e283bcdn%40chromium.org.

[Z Yin]

Thanks @salem. That's weird, I've published the same package 100+ times over the last 2 years with the exact same manifest (containing key), but just saw this error message today for the first time. It's also temporary – it disappeared on my 3rd try to upload, so I happily submitted it.

[hrg...@gmail.com]

I also include the "key" field in the manifest whenever I upload a new package. I've never had any problem with that, the CWS just ignores it.

It's actually a good thing that the CWS ignores this field because this allows us to test the new package locally as an unpacked extension (which needs the key field in order to preserve the extension ID).

If the CWS forced us to remove the key field, we would have to build the package twice, one with the "key" field and one without. Or, worse, build just once and then manually add/remove the key field from the manifest depending on whether we want to test the package locally or upload it.

[Cuyler Stuwe]

I build with the key.pem file included on initial deployment, and then leave it off for updated deployments (after the first upload, there’s no benefit from specifying… you’ve already locked the ID). 🤷‍♂️

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/5b4c9c9d-8a21-446d-8e5e-f3bdff5047aen%40chromium.org.

[hrg...@gmail.com]

I'm referring to the "key" field in the manifest. This field determines the extension ID when loading as an unpacked extension. This is the useful part.

Then, when you upload the package to the CWS, you don't need to remove that field, the developer dashboard allows you to keep it.

If the developer dashboard didn't allow the "key" field, we would need to remove it manually or adapt our build system to include the "key" or not depending on whether we want to test the package locally or upload it to the CWS

This hassle has never been necessary because the dashboard allows the "key" in the manifest even though it's not required.

I hope it's clear now.

[Cuyler Stuwe]

And what I’m saying is that you can include the private key that the public key is derived from as a “key.pem” file — this will also lock it to the corresponding ID.

After the initial upload to CWS, you don’t need to include the key file or the key field of the manifest; You couldn’t change the extension ID later even if you wanted.

I have always gotten this error that you’re talking about, so I’ve always used the method of bundling a “key.pem” file with success.

[hrg...@gmail.com]

There's no contradiction between what you are saying and what I'm saying. We are talking about different things.

Regarding the error you get when including the "key" field in the manifest. This happens if the key doesn't correspond to the extension you are updating. The dashboard looks at this field and makes sure it has the right value.

If field is not present, that's Ok too.