[tor-commits] r24801: {} Write down my thoughts on a simplified product package roadm (projects/roadmaps)

[Andrew Lewman]

Author: phobos
Date: 2011-06-04 03:00:06 +0000 (Sat, 04 Jun 2011)
New Revision: 24801

Added:
   projects/roadmaps/proposed-package-roadmap.txt
Log:
Write down my thoughts on a simplified product package roadmap.


Added: projects/roadmaps/proposed-package-roadmap.txt
===================================================================
--- projects/roadmaps/proposed-package-roadmap.txt	                        (rev 0)
+++ projects/roadmaps/proposed-package-roadmap.txt	2011-06-04 03:00:06 UTC (rev 24801)
@@ -0,0 +1,132 @@
+Proposed Package Roadmap
+
+I've been thinking about how we can simplify our product list and get
+back to focusing on what we're good at producing.  At the same time,
+getting more people involved in each others products can get us back
+to the idea we had at the 2010 Potsdam meeting where we had primary and
+secondary developers for each product.
+
+I propose we radically simplify our packages to the following four, for
+all operating systems we support:
+
+1. tor-client.  This is the tor browser bundle.
+2. tor-relay.  This is the tor binary with geoipdb, pre-configured as
+a non-exit relay.
+3. tor-exit-relay.  This is the tor binary with geoipdb, pre-configured
+as an exit relay.
+4. tor-bridge.  This is the tor binary with geoipdb, pre-configured as
+a publishing bridge.
+
+Why?
+
+We support a dizzying array of packages for an ever increasing number of
+operating systems.  Some packages you install, some are setup via native
+operating system packaging systems, some are just download and run.
+Developing a standard set of packages that contain the same things on
+different OSes should be possible. Users currently have to configure
+their software in varying ways, and then interact with their operating
+system and network devices to help the Tor network.  We should make it
+very easy to get tor running as the user wishes.
+
+It would make the user choice clear.  "I want to run tor as" can be
+answered by which package they download and install.  There is minimal
+configuration to be done, and the packages should just work 'out of the
+box'. 
+
+This could also reduce support load. Instead of supporting a billion
+apps and configs that may or may not be as anonymous/private as TBB, we
+just support TBB.  TBB becomes the focus on making it as zero-footprint
+and anonymous as possible.  
+
+(Where does this leave TAILS?  If one wants to 'torify' everything, then
+use TAILS; in a virtual machine, natively, whatever. If downloading TBB
+sucks, downloading TAILS would be horrible.  thandy updater for TAILS,
+or does that defeat the point of a read-only OS?)
+
+What does this mean practically for each major operating system we
+support?
+
+Microsoft Windows
+
+1. tor-client.  The same TBB we ship today.
+2. tor-relay. Vidalia and tor pre-configured as a non-exit relay.  Look
+at the current bridge-by-default bundle, just change the vidalia.conf to
+be a non-exit relay.
+3. tor-exit-relay. Vidalia and tor pre-configured as an exit relay.  Look
+at the current bridge-by-default bundle, just change the vidalia.conf to
+be an exit relay.
+4. tor-bridge. Vidalia and tor pre-configured as a bridge.  Look
+at the current bridge-by-default bundle.
+
+Apple OS X
+
+1. tor-client.  The same TBB we ship today.
+2. tor-relay.  Vidalia and tor pre-configured as a non-exit relay.
+Using TBB portable tor and vidalia, ship a vidalia.conf to be a non-exit
+relay.
+3. tor-exit-relay.  Vidalia and tor pre-configured as an exit relay.
+Using TBB portable tor and vidalia, ship a vidalia.conf to be an exit
+relay.
+4. tor-bridge.  Vidalia and tor pre-configured as a bridge.
+Using TBB portable tor and vidalia, ship a vidalia.conf to be a bridge.
+
+GNU/Linux (deb and rpm)
+
+1. tor-client.  The same TBB we ship today.
+2. tor-relay. Create tor-relay.(deb|rpm) that includes geoipdb and a
+pre-configured torrc that is for a non-exit relay.
+3. tor-exit-relay. Create tor-exit-relay.(deb|rpm) that includes geoipdb and a
+pre-configured torrc that is for an exit relay.
+4. tor-bridge. Create tor-bridge.(deb|rpm) that includes geoipdb and a
+pre-configured torrc that is for a bridge.
+
+Obvious issues (to me)
+
+1. If a user wants to run both a tor-client and
+tor-(relay|exit-relay|bridge) on the same host, we run into port
+conflicts.  At a minimum, the tor socks port, 9050 and control port,
+9051 show up right away.  For the tor-(relay|exit-relay|bridge)
+packages, one can disable the socks port altogether, and just leave the
+control port.  I believe there is some work to make vidalia and tor
+negotiate a control port number and choose that, assuming nothing else
+uses it.  This could be true for tor-* on start.  It can default to
+9050/9051, but if already taken, pick the next free port for socks and
+control.
+
+Alternatively, each package chooses a different socksport/control port
+combination.  
+
+2. Users will still run into firewalls, NAT routers, and the like while
+trying to get their tor relay working.  This is the same situation we
+have now, but it grossly simplifies the ability to get tor working.
+Step 1: install tor package of your choice
+Step 2: fight with your firewall/nat port-forwards
+If we get upnp working in tor itself, this may or may not make it easier
+for the users.
+
+3. The conversion from legacy to new packaging could be a mess.  Relay
+operators used to doing things one way will have to change.  Users used
+to installing tor and then configuring their apps will have to adjust.
+
+4. Installing a new tbb for every new release sucks, especially in
+places with little bandwidth.  Getting thandy working would solve this
+issue.  Having standardized packages for tor-clients may also make
+thandy deployment easier, as it's the same software in each package,
+just different binaries.
+
+5. The *BSD ports system would need to create different ports, or offer
+make options that enable the different configs for non-exit, exit, and
+bridge relay.  This is also true for fink/macports.
+
+Of course, users should be able to create their own packages, based on
+our published packaging scripts.
+
+Conclusion
+
+While a migration to a new set of packages could be painful, the world
+after the flag day would get easier and easier over time.  The package
+sets are simplified, nearly all of our problems with configuring tor as
+a relay or bridge go away, and it simplifies product management to
+defined channels.  We can then focus on security, anonymity, and
+usability fixes for each of the defined channels.  Improvements are
+pushed out across all operating systems for each channel.  


Property changes on: projects/roadmaps/proposed-package-roadmap.txt
___________________________________________________________________
Added: svn:mime-type
   + text/plain
Added: svn:eol-style
   + native