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.