Self Hosting Extension

[Clay Smith]

I have an extension published to testers. I'm working to convert this to a self hosted extension for faster management. I have provisioned firebase hosting and loaded the crx and xml following documentation below. Inspecting the headers all seems fine. On force install from the admin console I do not see the extension. I have updated my extensions, reloaded the policy and restarted the browser. 

Does anyone have any specific write-ups of this process beyond what I am reading below?

Thanks in advance.

//xml

<?xml version='1.0' encoding='UTF-8'?>

<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>

<app appid='obgxxxxxxxxxxxxxxxxxxxxxxxx'>

<updatecheck codebase='https://xxxxx/myextension/myextensioncrx' version='1.0.8' />

</app>

</gupdate>

https://developer.chrome.com/docs/apps/autoupdate/

http://www.dre.vanderbilt.edu/~schmidt/android/android-4.0/external/chromium/chrome/common/extensions/docs/autoupdate.html#H2-1

http://www.dre.vanderbilt.edu/~schmidt/android/android-4.0/external/chromium/chrome/common/extensions/docs/hosting.html

[Clay Smith]

Disregard. I had to surface the crx id using https://crx-checker.appspot.com/ which was different from the id I see when loaded in an unpacked version.

--
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/6ce26458-d74d-4d1f-a76e-0d985b45026fn%40chromium.org.

[Cuyler Stuwe]

I have some Node/Webpack code I've created for my browser extension template, to lock the ID on the first build.

This generates a public/private key pair, and then either includes the private key in the rendered output for initial uploads, or includes the public key in the manifest for local development.

If you don't do something like this to lock it, then the ID of your unpacked extension for local development will be a function of the extension's path on your local drive.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAEqtqY_jUvbLzsww8twk2wpc49Y8Lt9-7zt1ZGg7q_F%3DBLapjA%40mail.gmail.com.

[Clay Smith]

Great to know. I'm trying to contemplate a CI/CD model with this. How do you simplify the workflow?

[Cuyler Stuwe]

Since they're used solely to lock the ID of the extension and are generally not visible to untrusted others, I tend to commit these keys along with the codebase. There's no real impersonation risk once you've submitted your extension to the CWS once; It's not as though another extension can be submitted to a different account with the same ID.

As for CI/CD, depends on how you have it set up. 🤷‍♂️

For any given environment target, I have 3 build modes:

- Unpacked development. This puts the public key in the "key" property of the manifest, in order to lock the extension ID derived from it.
- Initial deploy. This puts the private key in a "key.pem" file in the root of your zipped extension. The CWS will consume this in and derive the extension ID from it.
- Updated deploy. This doesn't put any keys anywhere (historically, the CWS would panic if you included a key file or a key property in the manifest on package updates).

These are my relevant NPM scripts:

"generate-private-key": "2>/dev/null openssl genrsa 2048 | openssl pkcs8 -topk8 -nocrypt -out private-key.pem",
"generate-derived-public-key": "2>/dev/null openssl rsa -in private-key.pem -pubout -outform DER | openssl base64 -A -out public-key-base64.txt",
"generate-key-pair": "npm run generate-private-key && npm run generate-derived-public-key",
"generate-key-pair-if-not-generated": "(shx test -f private-key.pem && shx test -f public-key-base64.txt) || npm run generate-key-pair",
"copy-private-key-to-dist": "cp private-key-upload.pem dist/key.pem"

I have a manifest.js file that I run with Node to generate my manifest.json programmatically, and it starts off like this:

const manifest = {
    key: (
        process.env.BUILD_ENV === "local-dev"
            ? localPublicKeyText
            : undefined
    ),

//...

[Clay Smith]

Very helpful thanks for sharing all that. 

[Cuyler Stuwe]

Side note:

If you have a situation where you expect that your extension ID might be used essentially as application keys (e.g., with OAuth flows), then it might be worth storing these keys as env var secrets both locally and in your CI flows. 🤷‍♂️ 

That part is up to you, depending on your risk analysis. For most projects I've worked on, it wouldn't matter if someone got ahold of my private repo in order to spoof my ID in a sideloaded extension. But that's definitely something worth considering.