Change Since Chrome 73, only CRX3 format is supported

[GregDomjan]

CRX_HEADER_INVALID while dropping .crx into chrom://extensions tab

Failure to load since Chrome V73 is not considered an failure, but working as intended.

Seems that current format known as CRX2 used sha1,
CRX3 has hash upgrade to sha2 (haven't found detail on which sha2...)

Starting with Chrome 75, all force-installed extensions will need to be packaged in the CRX3 format. Privately hosted extensions that were packaged using a custom script or a version of Chrome prior to Chrome 64.0.3242.0 must be repackaged.If your organization is force-installing privately hosted extensions packaged in CRX2 format and you don’t repackage them, they’ll stop updating in Chrome 75. New installations of the extension will fail.Why is this change happening?

CRX2 uses SHA1 to secure updates to the extension. Breaking SHA1 is technically possible. So, an attacker might intercept the extension update and inject arbitrary code into it. CRX3 uses a stronger algorithm, avoiding this risk.

Feature request

• Support CRX3
• Support multiple formats (CRX2 might go, but CRX4 may come eventually...)
• For our users using old chrome version we might need to support building a CRX2 and CRX3.
  Would be nice to be able to do so in the same build, so would be helpful to be able to specify executions for multiple outputs, but default build of latest version seems reasonable.

[GregDomjan]

Some notes in attempt to make a pull request
CRXArchiveHelper
CRX_VERSION for v3
writeArchive the "header" has changed
v2

• pkey len
• sig len
• pkey
• zip sig
  v3
• head len
• "signed CRX head"
• pkey
• zip sig

CRXSignatureHelper
ALGORITHM = "SHA256withRSA";
https://chromium.googlesource.com/chromium/src/+/b8bc9f99ef4ad6223dfdcafd924051561c05ac75%5E%21/
https://cs.chromium.org/chromium/src/components/crx_file/crx_creator.cc?g=0&l=71

[spyhunter99]

i gave it a shot, i couldn't get the sha256 signed crx to start up with chrome. Getting the CRX_HEADER_INVALID error with what i believe is the correct headers and signing algorithm

[spyhunter99]

i made some progress with this. i now have an invalid signature with the v3 setup. the header is much different in v3 and their documentation isn't that great. Digging through chrome's source is pretty much the only option. I can write and verify my own v3 based crx files, by chrome doesn't like it, nor can i verify chrome generated crx files. giving up for now, the easier answer would be to just call chrome.exe from the command line with the appropriate options to pack and sign

[dgonzalo-sgt]

@spyhunter99 sorry to resurrect this old issue but, I'm on a similar situation... did you manage to get v3 crx files correctly or did you find another suitable alternative?
We'd like to package a crx extension in maven and this simplified things for us a lot...

[spyhunter99]

unfortunately no. what i described ended up being the solution in my case. I dropped usage of this plugin and used ant to zip up the sources, then call the chrome exe, assuming it can be found, with the command line options to sign the crx, passing in the cert info and passwords, etc. It works pretty well.

Using this solution removes the need to maintain this plugin, but now you definitely need to have chrome installed on the build machine. Only issue i can see is that google doesn't always provide support for features forever. Hopefully they won't remove the command line signing feature.

Maybe one day i will wrap the logic i have into a new maven plugin.

[dgonzalo-sgt]

unfortunately no. what i described ended up being the solution in my case. I dropped usage of this plugin and used ant to zip up the sources, then call the chrome exe, assuming it can be found, with the command line options to sign the crx, passing in the cert info and passwords, etc. It works pretty well.

Thanks for the update!

We are trying to create a jenkins CI for this for a privately hosted extension, using maven to package + nexus to host the .crx and it was working pretty well. Using the chrome.exe is not as clean (and we'll need Linux binaries), but it seems we reached a blocked path.

[GregDomjan]

Since we started to use node for some other tasks in our build, we found a node package that would do the same

  "devDependencies": {
    "crx": "^5.0.0"
  },
  "scripts": {
    "CRX3": "crx pack ./target/Chrome --crx-version 3 -o ./target/Chrome3.crx -p ./src/Chrome-browser-sign.pem",

[dgonzalo-sgt]

Since we started to use node for some other tasks in our build, we found a node package that would do the same

  "devDependencies": {
    "crx": "^5.0.0"
  },
  "scripts": {
    "CRX3": "crx pack ./target/Chrome --crx-version 3 -o ./target/Chrome3.crx -p ./src/Chrome-browser-sign.pem",

This is an interesting alternative, thanks!
I liked the nexus deploy option, as having the .crx there was a simple yet effective solution. I'll investigate if we can do the same with npm.