Sign Firefox extensions

In the light of recent events related to the release of Mozilla Firefox 48, which led a fraud among some users, due to the mandatory presence of signatures on the extensions, people who faced this problem faced a choice, either:
  1. Do not use unsigned extensions (bad option);
  2. Use unbranded builds
  3. go in a roundabout way, trying to disable checks by any means, some of which are suggested in the following comments:
    https://geektimes.ru/post/279132/#comment_9480372
    https://geektimes.ru/post/279132/#comment_9480382
  4. Sign the required extension yourself.

As you may have guessed, here we will talk about the last method. If we do not plan to distribute extensions through the official catalog, then we can get the signature without manual checks, i.e. simply and easily.

For this we need:
  1. addons.mozilla.org account
  2. installed nodejs version> = 0.10
  3. npm version> = 3.0.0 (npm up npm)
  4. jpm for nodejs (npm install jpm).

We will consider the signing process using the example of the "Random Agent Spoofer" extension. This extension contains a list of user agents that become outdated pretty quickly, and the add-on is not updated often. In turn, in the official repository, files with the data we need are updated regularly and there is a natural desire to put them into business.

So, the account is registered, the software environment is installed, you can proceed.

We take the experimental extension and unpack it into a separate folder, in our case we use the repository cast located at https://github.com/dillbyrne/random-agent-spoofer .
Get the following directory structure:
    test\
    lib\
    doc\
    data\
    .gitignore
    LICENSE
    package.json
    README.md

If you use a ready-made assembled extension, then in the root of the folder where it is unpacked, you need to delete the “bootstrap.js” and
“install.rdf” files , they are created by the build program, and when modifying already signed-in add-ons, the “META-INF” folder is also needed. Because If we are dealing with an add-on that has not yet been compiled, this is not required. The next step is to edit the file “package.json”, located again in the root of the directory of the unpacked extension. In our case, its beginning looks like this: If it contains the “id” parameter, it must either be changed or deleted. Otherwise, we get an error when trying to sign that we are not its owner. Next, we command the following "spell" to build the extension in the archive: or simply:
{
     "name": "random-agent-spoofer",
     "title": "Random Agent Spoofer",
     "id": "jid1-AVgCeF1zoVzMjA@jetpack",
     "description": "Allows the use of various browser profiles (including useragent ,platform, oscpu, accept headers and other options), which it can randomly switch between after a chosen period of time has expired",
     "author": "dbyrne",
     ...
}




jpm xpi --addon-dir <путь к папке куда распаковали>



jpm xpiif the current directory is the root of the unpacked extension.

The output should appear a file of the collected extension .xpi, which we will sign.

And now we’ll prepare our own api-key, for the sake of which we were registered at addons.mozilla.org . It can be seen at addons.mozilla.org/en/developers/addon/api/key as follows: where

Издатель JWT:
Секрет JWT:

- your personal key. And in conclusion, in fact, we carry out the signing act with the command: If everything goes smoothly and the automatic verification passes, then in the current directory we will receive the signed extension, which we needed. Useful links: jpm Documentation: developer.mozilla.org/en-US/Add-ons/SDK/Tools/jpm Signing Api: olympia.readthedocs.io/en/latest/topics/api/signing.html Thank you all for your attention good luck!

jpm sign --api-key --api-secret --xpi <путь к расширению полученному на предыдущем шаге>








Also popular now: