Software Update: Difference between revisions

Jump to navigation Jump to search

Software Update (view source)

Revision as of 02:04, 26 April 2005

1,459 bytes removed ,  26 April 2005
no edit summary
No edit summary
Line 18: Line 18:
=The Plan=
=The Plan=


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.
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 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.
Use signed JAR files 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 upon.  


<table style="float: right; width: 50%; border: 1px solid #999; margin: 6px; padding: 6px;">
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 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.).
<tr><td>
bsmedberg says: Why is the update a separate executable? What we would need to add to xpinstall is
 
# Binary-patch functionality
# Ability to do the xpinstall at shutdown/startup (not now)
 
Since we're planning on coding these features anyway, 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 to rename existing, in use files, put down the new ones, all with Firefox running. Then restart it, 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 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.).


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.).
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.).
Line 45: Line 30:
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.
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.


<table style="float: right; width: 50%; border: 1px solid #999; margin: 6px; padding: 6px;">
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.
<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.


<table style="float: right; width: 50%; border: 1px solid #999; margin: 6px; padding: 6px;">
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 unpack the JAR and signal Firefox to start the upgrade process.
<tr><td>
Comments 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?
</table>


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.
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?


==Processing the Update==
==Processing the Update==


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.
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 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.
Benjamin Smedberg
Confirmed users, Bureaucrats and Sysops emeriti
1,217

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/5602"

Navigation menu