Self-hosted Add-on does not detect updadtes

Add-ons Development
#1

I am trying to set up automatic updates for an add-on that, previously, I was pushing out manually (“Hey people, the new XPI file is at xyz.com/foobar.xpi”).

I have read the doc page for package.json as well as jpm, and I have been Googling left and right to no avail. Here is how I have it configured and how I have tested it:

Configuration:

  1. In package.json I have specified both updateLink and updateURL
  2. Both are pointing to the same HTTPS server
  3. Entering either URL directly in the browser correctly retrieves the associated file. In the case of the rdf, I get back MIME type application/rdf+xml, which I believe is correct. If I attempt direct access to the xpi file, Firefox blocks it as an unauthorized attempt to install software (which is the expected behavior)
  4. Package.json has an “engines” entry for “firefox” of “>=38.0.a1 <=45.0” which correctly transfers to the <minVersion> and <maxVersion> entries in the rdf file (figuring out the correct package.json syntax for this was a struggle in itself)

Testing:

  1. I use jpm sign to get the starting version, say 1.0.0 and I load it manually into FF (44.0.2)
  2. I update package.json and set the version to 1.0.1
  3. I run jpm xpi to get the update.rdf file
  4. I run jpm sign to get a signed version of the xpi
  5. I upload the rdf and xpi files to the locations identified in updateURL and updateLink, respectively
  6. In FF, I select “Check for updates” and get the result “No updates available”

I have no idea at this point what I might be doing wrong. Any help is appreciated.

#2

Look in the console to see what messages you get about the update check. Messages are generated at javascript log level and should tell you what it found.

Double-check the format of the update manifest. I haven’t used jpm to generate it, only manually.

#3

Thanks for the reply. N00b that I am, I was expecting Firebug’s console to show any errors, which of course it can’t. Opening up the browser toolbox showed me that I was getting “NS_ERROR_ABORT: Certificate issuer is not built-in.”

So if I’m a n00b for add-on development, I’m a particularly under-educated infant when it comes to SSL certs. I hit the Google and I can guess that Avast AV could be getting in the way, or otherwise Dropbox itself (where I’m hosting the files) has an issue. I was able to get my add-on to update by adding “extensions.update.requireBuiltInCerts=false” into about:config.

That’s probably not a practical long-term solution, however. I can’t ask the people using the add-on to disable their AV and most of them probably aren’t skilled enough to fiddle with about:config. I’m not sure I want to ask them to disable that option in any case. I read this discussion at bugzilla and there is apparently some argument about how secure (or not) the requirement for built-in certs makes add-on installation & updating.

I am now looking into McCoy and delivering updates over HTTP, but it’s not encouraging. The doc file for jpm says that the updateLink parameter must be HTTPS. I will have to see if it’s only the RDF file that is getting hit with the non-built-in cert error (and so I can keep the xpi on HTTPS) or if the blog/forum posts about how to use McCoy to get around this issue are outdated.

#4

This may not be anything to do with Avast (although it could be). The error indicates that the certificate root from your host is not known (built in) to Firefox. This may be the case if you have signed your own certificate rather than getting it from a certificate authority. Alternatively, the error can be caused by communication from your website being “intercepted” by a firewall or even your ISP (or even an attacker, but probably not in this case).

#5

Thanks. The files are hosted on Dropbox, so if the cert isn’t built into Firefox there’s not going to be much I can do about it. I know that Avast is “scanning” SSL traffic and if what I read is correct, it behaves like an SSL proxy when it does that. I will be testing the update behavior with the SSL scanning disabled. All of my AMO-hosted addons update fine, of course, but my guess is that FF has an exception for the certificate rules for those so that any antivirus shenanigans or, say, corporate SSL proxy issues are bypassed.