[or-cvs] r15925: An initial check in of the automatic update program. Mixed i (tor/trunk/doc/spec/proposals)

ioerror at seul.org ioerror at seul.org
Tue Jul 15 07:20:55 UTC 2008 

Author: ioerror
Date: 2008-07-15 03:20:55 -0400 (Tue, 15 Jul 2008)
New Revision: 15925

Added:
   tor/trunk/doc/spec/proposals/153-automatic-software-update-protocol.txt
Log:
An initial check in of the automatic update program. Mixed ideas, needs much work and spliting.


Added: tor/trunk/doc/spec/proposals/153-automatic-software-update-protocol.txt
===================================================================
--- tor/trunk/doc/spec/proposals/153-automatic-software-update-protocol.txt	                        (rev 0)
+++ tor/trunk/doc/spec/proposals/153-automatic-software-update-protocol.txt	2008-07-15 07:20:55 UTC (rev 15925)
@@ -0,0 +1,175 @@
+Filename: 153-automatic-software-update-protocol.txt
+Title: Automatic software update protocol
+Version: $Revision$
+Last-Modified: $Date$
+Author: Jacob Appelbaum 
+Created: 14-July-2008
+Status: Draft
+
+
+                      Automatic Software Update Protocol Proposal
+
+0.0 Introduction
+
+The Tor project and its users require a robust method to update shipped
+software bundles. The software bundles often includes Vidalia, Privoxy, Polipo,
+Torbutton and of course Tor itself. It is not inconcievable that an update
+could include all of the Tor Browser Bundle. It seems reasonable to make this 
+a standalone program that can be called in shell scripts, cronjobs or by
+various Tor controllers.
+
+0.1 Minimal Tasks To Implement Automatic Updating
+
+At the most minimal, an update must be able to do the following: 
+
+    0 - Detect the curent Tor version, note the working status of Tor.
+    1 - Detect the latest Tor version. 
+    2 - Fetch the latest version in the form of a platform specific package(s).
+    3 - Verify the itegrity of the downloaded package(s).
+    4 - Install the verified package(s).
+    5 - Test that the new package(s) works properly.
+
+0.2 Specific Enumeration Of Minimal Tasks
+
+To implement requirement 0, we need to detect the current Tor version of both 
+the updater and the current running Tor. The update program itself should be 
+versioned internally. This requirement should also test connecting through Tor 
+itself and note if such connections are possible.
+
+To implement requirement 1, we need to learn the concensus from the directory 
+authorities or fail back to a known good URL with cryptographically signed 
+content.
+
+To implement requirement 2, we need to download Tor - hopefully over Tor.
+
+To implement requirement 3, we need to verify the package signature.
+
+To implement requirement 4, we need to use a platform specific method of 
+installation. The Tor controller performing the update perform these platform 
+specific methods.
+
+To implement requirement 5, we need to be able to extend circuits and reach 
+the internet through Tor.
+
+0.x Implementation Goals
+
+The update system will be cross platform and rely on as little external code 
+as possible. If the update system uses it, it must be updated by the update 
+system itself. It will consist only of free software and will not rely on any 
+non-free components until the actual installation phase. If a package manager 
+is in use, it will be platform specific and thus only invoked by the update 
+system implementing the update protocol.
+
+The update system itself will attempt to perform update related network 
+activity over Tor. Possibly it will attempt to use a hidden service first.
+It will attempt to use novel and not so novel caching 
+when possible, it will always verify cryptographic signatures before any 
+remotely fetched code is executed. In the event of an unusable Tor system, 
+it will be able to attempt to fetch updates without Tor. This should be user 
+configurable, some users will be unwilling to update without the protection of 
+using Tor - others will simply be unable because of blocking of the main Tor 
+website.
+
+The update system will track current version numbers of Tor and supporting 
+software. The update system will also track known working versions to assist 
+with automatic The update system itself will be a standalone library. It will be 
+strongly versioned internally to match the Tor bundle it was shiped with. The 
+update system will keep track of the given platform, cpu architecture, lsb_release, 
+package management functionality and any other platform specific metadata.
+
+We have referenced two popular automatic update systems, though neither fit 
+our needs, both are useful as an idea of what others are doing in the same 
+area.
+
+The first is sparkle[0] but it is sadly only available for Cocoa 
+environments and is written in Objective C. This doesn't meet our requirements 
+because it is directly tied into the private Apple framework.
+
+The second is the Mozilla Automatic Update System[1]. It is possibly useful 
+as an idea of how other free software projects automatically update. It is 
+however not useful in its currently documented form.
+
+
+    [0] http://sparkle.andymatuschak.org/documentation/
+    [1] http://wiki.mozilla.org/AUS:Manual
+
+0.x Previous methods of Tor and related software update
+
+Previously, Tor users updated their Tor related software by hand. There has
+been no fully automatic method for any user to update. In addition, there
+hasn't been any specific way to find out the most current stable version of Tor
+or related software as voted on by the directory authority concensus.
+
+0.x Changes to the directory specification
+
+We will want to supplement client-versions and server-versions in the 
+concensus voting with another version identifier known as 
+'auto-update-versions'. This will keep track of the current concensus of 
+specific versions that are best per platform and per architecture. It should 
+be noted that while the Mac OS X universal binary may be the best for x86 
+processers with Tiger, it may not be the best for PPC users on Panther. This 
+goes for all of the package updates. We want to prevent updates that cause Tor 
+to break even if the updating program can recover gracefully.
+
+x.x Assumptions About Operating System Package Management
+
+It is assumed that users will use their package manager unless they are on 
+Microsoft Windows (any version) or Mac OS X (any version). Microsoft Windows 
+users will have integration with the normal "add/remove program" functionality 
+that said users would expect.
+
+x.x Package Update System Failure Modes
+
+The package update will try to ensure that a user always has a working Tor at 
+the very least. It will keep state to remember versions of Tor that were able 
+to bootstrap properly and reach the rest of the Tor network. It will also keep 
+note of which versions broke. It will select the best Tor that works for the 
+user. It will also allow for anonymized bug reporting on the packages 
+available and tested by the auto-update system.
+
+x.x Package Signature Verification
+
+The update system will be aware of replay attacks against the update signature 
+system itself. It will not allow package update signatures that are radically 
+out of date. It will be a multi-key system to prevent any single party from 
+forging an update. The key will be updated regularly. This is like authority 
+key (see proposal 103) usage.
+
+x.x Package Caching
+
+The update system will iterate over different update methods. Whichever method 
+is picked will have caching functionality. Each Tor server itself should be 
+able to serve cached update files. This will be an option that friendly server 
+administrators can turn on should they wish to support caching. In addition, 
+it is possible to cache the full contents of a package in an 
+authoratative DNS zone. Users can then query the DNS zone for their package. 
+If we wish to further distribute the update load, we can also offer packages 
+with encrypted bittorrent. Clients who wish to share the updates but do not 
+wish to be a server can help distribute Tor updates. This can be tied together 
+with the DNS caching[2][3] if needed.
+
+    [2] http://www.netrogenic.com/dnstorrent/
+    [3] http://www.doxpara.com/ozymandns_src_0.1.tgz
+
+x.x Helping Our Users Spread Tor
+
+There should be a way for a user to participate in the packaging caching as 
+described in section x.x. This option should be presented by the Tor 
+controller.
+
+x.x Simple HTTP Proxy To The Tor Project Website
+
+It has been suggested that we should provide a simple proxy that allows a user 
+to visit the main Tor website to download packages. This was part of a 
+previous proposal and has not been closely examined.
+
+x.x Package Installation
+
+Platform specific methods for proper package installation will be left to the 
+controller that is calling for an update. Each platform is different, the 
+installation options and user interface will be specific to the controller in 
+question.
+
+x.x Other Things
+
+Other things should be added to this proposal. What are they?

More information about the tor-commits mailing list