Open GregDomjan opened 5 years ago
Some notes in attempt to make a pull request CRXArchiveHelper CRX_VERSION for v3 writeArchive the "header" has changed v2
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
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
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
@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...
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.
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.
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",
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.
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...)
Feature request