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