Changes

Add a module to Firefox to support Revise the downloading of an update existing toolkit code which downloads XPIupdates. 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 XPIs signed JAR files to deliver the update. The update itself will be an contain a manifest of files which need updating/removal, and may also run executable that will be run by Firefox when it detects that a XPI has been fully downloadedprograms. This 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 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.

<table style="float: right; width: 50%; border: 1px solid #999; margin: 6px; padding: 6px;"><tr><td>bsmedberg says: Why is The application must not be running while the update a separate executable? What we would need to add to xpinstall is # Binary-patch functionality# Ability to do being installed. Our systems, including the xpinstall at shutdown/startup (not now) Since we're planning on coding these features anywayJAR cache, let's do it right! I can't see that it would take a lot more time than creating separate update executables for each update.</table> <table style="float: right; width: 50%; border: 1px solid #999; margin: 6px; padding: 6px;"><tr><td>Silver says: on NT-based OSes, you can at least rename files that are loaded as part of an application. This would allow you not designed to deal with changes to rename existing, in use their underlying files, put down the new ones, all with Firefox running. Then restart itIn addition, and clean up the old ones in the background.</table> 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 The Firefox before updating itexecutable will run a separate update binary (using execv or another method). The This executable will process the update executable manifest and will wait for Firefox to shutdown before it begins updating Firefox. It may either replace individual files or leverage the binary patching (see technology of [http://www.daemonology.net/bsdiff/ bsdiff](with modifications for reliability) to update Firefox. Once the update executable completes, it will re-launch Firefox passing it a command line flag to instruct Firefox that it has just been updatedthe Firefoxs executable. This will allow Firefox to perform any post -upgrade steps operations (e.g., modifying registry keys, etc.).

<table style="float: right; width: 50%; border: 1px solid #999; margin: 6px; padding: 6px;"><tr><td>Comments from bsmedberg: are we sure that the mozilla mirror network supports byte-range requests properly? Is there some other way to gate bandwidth?</table> 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. Note: We need to test the byte-range request support of Mozilla's mirror network.

<table style="float: right; width: 50%; border: 1px solid #999; margin: 6px; padding: 6px;"><tr><td>Comments from bsmedberg: We should think carefully about how we handle these signatures. I presume we want mozilla updates to Once the XPI has been completely downloaded, it's signature will be signed *by mozillaverified.org* If the signature checks out, not just signed in generalthen assuming that Firefox has permission from the user, it will unpack the JAR and signal Firefox to start the upgrade process. How do we identify which cert/certchains are appropriate?</table>

Once the XPI has been completely downloaded, it's signature will Note from bsmedberg: We should think carefully about how we handle these signatures. I presume we want mozilla updates to be verifiedsigned *by mozilla. If the signature checks outorg*, 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 directorynot just signed in general.How do we identify which cert/certchains are appropriate?

At startup, Firefox will look for an update executable manifest in a fixed location. If it finds the executablemanifest, then assuming it has permission from the user it will launch the update executable and exit. Once the update executable determines to process that Firefox has exited, it will begin applying the updatesmanifest.