Distributing Chrome Extensions for older versions of chrome (CRX_VERSION_NUMBER_INVALID)
For anyone who has not done it, deploying Software as a Service into an Enterprise environment is an interesting experience. Not only do you have to navigate myriad of policies, access restrictions, and firewalls but you are also more often than not, working with legacy operating systems and software due to the level of rigour and stability required in an Enterprise desktop build
We recently experienced this joy first hand when deploying our Gurn software to run a pilot with a FTSE 100 company. The client was running an older version of Chrome — 57.0, now this isn’t an ancient version by any stretch having been released in March 2017, but in the world of continuous deployment a lot can change over a short period of time. At the time of writing (16 months since the release of Chrome 57), Chrome has already moved on to version 67.0 and with those versions have come lots of new features.
What was the problem?
In order to distribute our extension to this client, we had to pack and sign our extension manually rather than distribute it through the chrome store as we usually would.
Packing an extension is a simple process, you load the unpacked extension in chrome and click the pack button which packages and digitally signs the extension for distribution. We sent the packed extension to the client to test and they received the following error.
Package is invalid: ‘CRX_VERSION_NUMBER_INVALID’They couldn’t install the package and I was none the wiser as to why. After hunting around the internet for a solution to no avail, I took the plunge into the Chromium source code to try and figure out what was going on.
I discovered that the Chrome extension unpacker checks the version of the CRX format that the extension is packaged with vs the version supported by the browser. If the version numbers differ Chrome throws an error.
This error is never given when distributing through the Chrome store as I assume it is straightforward for them to check the version of the browser making the request and send a package with the correct CRX format.
The fix
Sometime between Chrome 57 and Chrome 67 (I got bored looking!) the CRX version being used for packaging was upgraded to version 2. I wasn’t sure exactly when this change had occurred, but now that I understood the check that the browser was making, I had a possible solution to the problem. If I packaged the extension using the same version of the browser as the client, the version check should pass as it will be using the correct CRX format. I downloaded the Chrome 57 browser from https://www.slimjet.com/chrome/google-chrome-old-version.php, packed the extension and ran a test install and the problem was solved.
I appreciate that this is a niche area of concern, but I’m sure this will be useful to others running into the same problem in the future.
