|
|
| Line 24: |
Line 24: |
| * '''Bug: Disable automated updates for the system add-ons location''' | | * '''Bug: Disable automated updates for the system add-ons location''' |
|
| |
|
| During runtime the client will periodically check for system add-ons to use with the current application version. It will do so by making a HTTPS request to a specific URL which will return a root manifest listing the system add-ons for that application, the versions they are compatible with and the URL of a normal [https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility update manifest] for each add-on. | | During runtime the client will periodically make a HTTPS request to a specific URL including data on the application channel, version and OS The manifest returned lists the specific system add-ons that should be used with that application. |
|
| |
|
| Here is a proposed root manifest format. It allows for multiple client applications to use the same manifest file but assumes that most system add-ons will only work with a single client application.
| | An example of the data the manifest must include: |
|
| |
|
| { | | { |
| "<app-ID>": { | | "<addon-1-ID>": { |
| "<addon-ID>": { | | "version": "1.2.0", |
| "minVersion": "42.0",
| | "xpiURL": "http://mozilla.com/foo/bar/addon1.xpi", |
| "maxVersion": "45.*",
| | "xpiHash": "sha256:38974658476582645723465802458972345", |
| "updateManifest": "https://mozilla.com/foo/bar/update.rdf"
| | }, |
| } | | |
| | "version": "1.0.0", |
| | "xpiURL": "http://mozilla.com/foo/bar/addon2.xpi", |
| | "xpiHash": "sha256:45676878579689577567674563576746746", |
| } | | } |
| } | | } |
|
| |
|
| The minVersion and maxVersion here are hints for the client application to help reduce the bandwidth when we know that a given system add-on isn't compatible with the application. minVersion defaults to "0" if missing, maxVersion defaults to "*". Most likely a new system add-on will be added with a defined minVersion for the first supported client version with maxVersion omitted. Later when the add-on reaches end of life the maxVersion property would be added. This keeps the need to modify the root manifest to a minimum, only when a new system add-on is created and when one is retired, more complex compatibility information is supported in the update manifest.
| | This manifest could be a standalone file or embedded in the existing update.xml file somewhere. The former is a little easier to implement on the client side. |
|
| |
|
| If the application version falls in the range then the the update manifest is downloaded and used to find a compatible XPI to install. If the application version doesn't fall in the range then it assumes that there is no compatible XPI available.
| | Any add-on versions that are not already available locally are downloaded and checked against the given hash (is this needed given that we're signing the add-ons too?). |
|
| |
|
| * '''Bug: Periodically download the system add-ons root manifest''' | | * '''Bug: Download and install new system add-ons''' |
|
| |
|
| If there is no compatible XPI available for an installed system add-on then it will be uninstalled.
| | Once all the add-on versions listed in the manifest are available locally this list replaces the current known-good set, any enabled system add-ons not in the set are disabled, any system add-ons in the set not enabled are enabled. |
|
| |
|
| * '''Bug: Uninstall system add-ons when no compatible version exists for the current application version''' | | * '''Bug: Replace the current set of system add-ons with the new known-good set''' |
| | |
| If there is a compatible XPI available then it will be downloaded and installed unless that specific add-on version is already installed. Note this differs from normal add-on update where we only download newer versions, here we can also downgrade the system add-on.
| |
| | |
| * '''Bug: Download and install compatible system add-ons when no matching version is installed'''
| |
| | |
| The actual host of the update manifest and the XPIs that it points to doesn't matter to the client code. It could be AMO or something new. Changing the host in the future only requires changing the root manifest, no client changes would be necessary.
| |
|
| |
|
| =Securing system add-ons= | | =Securing system add-ons= |