Changes

Use signed JAR files a XPI-like package to deliver the update. The update itself will contain a manifest of files which need updating/removal, and may also run executable programs. 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 yet to be decided uponby 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 will 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 Firefoxs executable. This will allow Firefox to perform any post-upgrade operations (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 currently an RDF a simple XML file) over HTTPS that will point Firefox at the right XPI update package to download.

In silent download mode, Firefox will use byte-range requests (supported by HTTP and FTPthe Mozilla.org mirror network) to download the XPI update package in small pieces. Each time Firefox starts up it will check to see if it should resume downloading the XPIupdate package. It will not try to download the XPI 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. Note: We need to test the byte-range request support of Mozilla's mirror network.

Once the XPI update package has been completely downloaded, it's signature integrity will be verifiedby 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 signature hash checks out, then assuming that Firefox has permission from the user, it will unpack the JAR update package and signal Firefox to start the upgrade process. Note from bsmedberg: We should think carefully about how we handle these signatures. I presume we want mozilla updates to be signed *by mozilla.org*, not just signed in general. How do we identify which cert/certchains are appropriate?