Software Update: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
m (it's => its)
 
(45 intermediate revisions by 16 users not shown)
Line 1: Line 1:
=Overview=
=Overview=


This page describes a plan for improving software update for Firefox, Thunderbird and other applications.  (I'll refer specifically to Firefox from now on.)
This page describes a plan for improving software update for Firefox, Thunderbird and other applications.  (I'll refer specifically to Firefox from now on.) See also [[Firefox:1.1_Software_Update_Upgrades|Firefox 1.5: Software Update]].
 
Module owners: [https://wiki.mozilla.org/Modules/All#Update_Service Update Service] module.


==Requirements==
==Requirements==
Line 11: Line 13:
* Allow users to easily view and control the process
* Allow users to easily view and control the process


==The Plan==
==Schedule==
 
Security updates are a reality, so we need a better way to push out updates to people who
desire them.  With that in mind, the goal is to implement this system for Firefox 1.5.
 
= The Plan =
 
Revise the existing toolkit code which downloads XPI updates. Provide a silent mode that will be used for security updates. Do this only if the user has agreed (via some UI during installation perhaps) and only if the user has write permission to the installation directory. We don't want this update system to get in the way of RPM or MSI based solutions, etc.
 
Use a XPI-like package to deliver the update. The update itself will contain a manifest of files which need updating/removal. The update may happen once the download is complete, at app shutdown, or the next time Firefox is launched. That behavior is a policy decision to be decided upon by the user-facing update service.
 
The application must not be running while the update is being installed. Our systems, including the JAR cache, are not designed to deal with changes to their underlying files. In addition, the Windows filesystem does not allow files to be unlinked from their parent directory while they are in use. The Firefox executable will run a separate update binary (using execv or another method). This executable will process the update manifest and may leverage the binary patching technology of [http://www.daemonology.net/bsdiff/ bsdiff] (with modifications for reliability). Once the update executable completes, it will re-launch the Firefox executable. This will allow Firefox to perform any post-upgrade operations (e.g., modifying registry keys, etc.).


Add a module to Firefox to support the downloading of an update XPI. Provide a silent mode that will be used for security updates.  Do this only if the user has agreed (via some UI during installation perhaps) and only if the user has write permission to the installation directory.  We don't want this update system to get in the way of RPM or MSI based solutions, etc.
Users will have the option to view silent upgrade progress, and choose to cancel, suspend, or "complete it now." They will also be provided with simple controls to alter the upgrade policy (notifications, silent or not, etc.).  


Use XPIs to deliver the update.  The update itself will be an executable that will be run by Firefox when it detects that a XPI has been fully downloaded.  This may happen once the download is complete, at app shutdown, or the next time Firefox is launched.  That behavior is a policy decision yet to be decided upon.  Using XPIs to deliver the update executable allows us to leverage the existing support for signed XPIs.  Moreover, we have the option of packaging an entire install executable in the XPI if that is deemed appropriate.
== Downloading the Update ==


The Windows filesystem does not allow files to be unlinked from their parent directory while they are in use.  This means that we have to shutdown Firefox before updating it. The update executable will wait for Firefox to shutdown before it begins updating Firefox.  It may either replace individual files or leverage binary patching (see [http://www.daemonology.net/bsdiff/ bsdiff]) to update Firefox. Once the update executable completes, it will launch Firefox passing it a command line flag to instruct Firefox that it has just been updated.  This will allow Firefox to perform any post upgrade steps (e.g., modifying registry keys, etc.).
Firefox will periodically check the Mozilla.org update servers (AUS) for available updates. The update server will return a manifest file (which is a simple XML file) over HTTPS that will point Firefox at the right update package to download.  


Users will have the option to view silent upgrade progress, and choose to cancel, suspend, or "complete it now."  They will also be provided with simple controls to alter the upgrade policy (notifications, silent or not, etc.).
In silent download mode, Firefox will use byte-range requests (supported by the Mozilla.org mirror network) to download the update package in small pieces. Each time Firefox starts up it will check to see if it should resume downloading the update package. It will not try to download the update package while Firefox is not running. This simplifies the implementation of the downloading system because it enables us to make use of the Firefox networking stack. Firefox will try to minimally impact the user's network bandwidth in the process.  


==Downloading the Update==
Once the update package has been completely downloaded, its integrity will be verified by computing a hash (e.g., SHA-2) over the entire update package. This hash will be compared to a hash included in the XML file received from AUS. If the hash checks out, then assuming that Firefox has permission from the user, it will unpack the update package and signal Firefox to start the upgrade process.


Firefox will periodically check the Mozilla.org update servers for available updates.  The update server will return a manifest file (which is currently an RDF file) that will point Firefox at the right XPI to download.
== Processing the Update ==


In silent download mode, Firefox will use byte-range requests (supported by HTTP and FTP) to download the XPI in small pieces. Each time Firefox starts up it will check to see if it should resume downloading the XPI.  It will not try to download the XPI while Firefox is not running.  This simplifies the implementation of the downloading system because it enables us to make use of the Firefox networking stack.  Firefox will try to minimally impact the user's network bandwidth in the process.
At startup, Firefox will look for an update manifest in a fixed location. If it finds the manifest, then assuming it has permission from the user it will launch the update executable to process that manifest.  


Once the XPI has been completely downloaded, it's signature will be verified. If the signature checks out, then assuming that Firefox has permission from the user, it will install the XPI. The XPI will have a very simple install.js file that will copy the upgrade executable into the correct location within the Firefox installation directory.
Before making any changes to the existing Firefox installation, the update executable will scan all files to be modified and verify that they are the expected version. If it finds that any files are not in sync with what it expects to find, then it will not apply the update. Otherwise, it will proceed to either: add, remove, replace, or patch existing files.  


==Processing the Update==
Before the update executable exits, it will record status to a log file that will be read by Firefox on next launch to determine if the update was successfully applied. This will allow Firefox to present good UI to the user in the advent of an unexpected problem.


At startup, Firefox will look for an update executable in a fixed location.  If it finds the executable, then assuming it has permission from the user it will launch the update executable and exit.  Once the update executable determines that Firefox has exited, it will begin applying the updates.
== Windows Update Service ==


Before making any changes to the existing Firefox installation, the update executable will scan all files to be modified and verify that they are the expected version.  If it finds that any files are not in sync with what it expects to find, then it will not apply the update.  Otherwise, it will proceed to either: add, remove, replace, or patch existing files.
An enhancement will be made to use a windows service to silently update the application. [[Windows Service Silent Update]]


Before the update executable exits, it will record status to a log file that will be read by Firefox on next launch to determine if the update was successfully applied.  This will allow Firefox to present good UI to the user in the advent of an unexpected problem.
=Comments=


==Comments==
If you have any comments on this plan, please add them to the [[Talk:Software_Update|Discussion]] page.


If you have any comments on this plan, please feel free to drop me a line: [mailto:darin@meer.net darin@meer.net]
=Links=
* [[Software Update:User Interface]]
* [[Software Update:Checking For Updates]]
* [[Software Update:Update Management]]
* [[Software Update:Channels]]
* [[Software Update:Service Components]]
* [[Software Update:Processing Updates]]
* [[Software Update:MAR]]
* [[Software Update:MAR_Signing_and_Verification]]
* [https://bugzilla.mozilla.org/show_bug.cgi?id=290390 Tracking Bug]
* [[Software_Update:Signing]]
* [[Software Update:Tasklist]]
* [[Software Update:Testing]]
* [[Software_Update:Manually_Installing_a_MAR_file]]
* [[Software_Update:updates.xml Format]]
* [[Software_Update:Nightly_update_infrastructure]]
* [[Software_Update:Major Update Use Cases]]
* [[Software_Update:HowToTestMajorUpdateUI]]
* [[Software_Update:HowToManuallyGenerateMARFiles]]
* [[Software_Update:GeneratingSnippetsAndPartialsForReleases]]

Latest revision as of 21:00, 25 August 2016

Overview

This page describes a plan for improving software update for Firefox, Thunderbird and other applications. (I'll refer specifically to Firefox from now on.) See also Firefox 1.5: Software Update.

Module owners: Update Service module.

Requirements

  • Support for silent or explicit downloading
  • Support for binary patching or full upgrade
  • Support for cryptographic signatures
  • Minimize impact on backend build and distribution processes
  • Allow users to easily view and control the process

Schedule

Security updates are a reality, so we need a better way to push out updates to people who desire them. With that in mind, the goal is to implement this system for Firefox 1.5.

The Plan

Revise the existing toolkit code which downloads XPI updates. Provide a silent mode that will be used for security updates. Do this only if the user has agreed (via some UI during installation perhaps) and only if the user has write permission to the installation directory. We don't want this update system to get in the way of RPM or MSI based solutions, etc.

Use a XPI-like package to deliver the update. The update itself will contain a manifest of files which need updating/removal. The update may happen once the download is complete, at app shutdown, or the next time Firefox is launched. That behavior is a policy decision to be decided upon by the user-facing update service.

The application must not be running while the update is being installed. Our systems, including the JAR cache, are not designed to deal with changes to their underlying files. In addition, the Windows filesystem does not allow files to be unlinked from their parent directory while they are in use. The Firefox executable will run a separate update binary (using execv or another method). This executable will process the update manifest and may leverage the binary patching technology of bsdiff (with modifications for reliability). Once the update executable completes, it will re-launch the Firefox executable. This will allow Firefox to perform any post-upgrade operations (e.g., modifying registry keys, etc.).

Users will have the option to view silent upgrade progress, and choose to cancel, suspend, or "complete it now." They will also be provided with simple controls to alter the upgrade policy (notifications, silent or not, etc.).

Downloading the Update

Firefox will periodically check the Mozilla.org update servers (AUS) for available updates. The update server will return a manifest file (which is a simple XML file) over HTTPS that will point Firefox at the right update package to download.

In silent download mode, Firefox will use byte-range requests (supported by the Mozilla.org mirror network) to download the update package in small pieces. Each time Firefox starts up it will check to see if it should resume downloading the update package. It will not try to download the update package while Firefox is not running. This simplifies the implementation of the downloading system because it enables us to make use of the Firefox networking stack. Firefox will try to minimally impact the user's network bandwidth in the process.

Once the update package has been completely downloaded, its integrity will be verified by computing a hash (e.g., SHA-2) over the entire update package. This hash will be compared to a hash included in the XML file received from AUS. If the hash checks out, then assuming that Firefox has permission from the user, it will unpack the update package and signal Firefox to start the upgrade process.

Processing the Update

At startup, Firefox will look for an update manifest in a fixed location. If it finds the manifest, then assuming it has permission from the user it will launch the update executable to process that manifest.

Before making any changes to the existing Firefox installation, the update executable will scan all files to be modified and verify that they are the expected version. If it finds that any files are not in sync with what it expects to find, then it will not apply the update. Otherwise, it will proceed to either: add, remove, replace, or patch existing files.

Before the update executable exits, it will record status to a log file that will be read by Firefox on next launch to determine if the update was successfully applied. This will allow Firefox to present good UI to the user in the advent of an unexpected problem.

Windows Update Service

An enhancement will be made to use a windows service to silently update the application. Windows Service Silent Update

Comments

If you have any comments on this plan, please add them to the Discussion page.

Links