Hi!
Here is a report from DebConf 11, the annual conference of the Debian project. We had the opportunity to hold a "Tor ecosystem" BoF. It was short (we had only 45 minutes), but productive from my perspective. Here's an (obviously partial) report.
A lot more people showed up (± 25) than we expected for a pure work meeting, so there is definitely an interest in having Tor and its ecosystem working well in Debian. Among the attendees we had: * Peter Palfrader, maintainer of the 'tor' package, * Ulises Vitulli, (co-)maintainer of 'vidalia', 'tor-arm', 'python-torctl', 'torchat', * Jérémy Bobbio, maintainer of 'torbutton', * intrigeri and bertagaz, developers of Tails (which is a live system based on Debian).
A summary follows from some notes and memory. Feel free to correct me if you feel that things happened differently.
New upstream packaging policy =============================
We took some time to discuss the changes to the packaging policy that were proposed by Andrew Lewman last June. See https://lists.torproject.org/pipermail/tor-dev/2011-June/002780.html
Quoting the relevant part:
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.
The 'tor' source package in Debian already builds a binary package called 'tor-geoipdb' which contains GeoIP information. We have not even discussed about changing, as it is how it is supposed to be in Debian (pure data package as separate, architecture-independent packages).
The proposed 'tor-client' and TBB in general was discussed later. For the rest, the hard part of the discussion also revolved around defining who are target users of these packages. Pure desktop users? People that can fiddle with a command-line and edit a configuration file? Experienced sysadmins?
Having 3 different "configuration" packages for relays, exit-relays and bridges is something that could be done in Debian. But we had a rough consensus that it would actually complicate things for most Debian users.
For bridges, pure desktop users would probably benefit from a better integration with Vidalia; so that made us rule out the need for a dedicated 'tor-bridge' package.
Which left us with the "relay" and "exit relay" use cases and it looked like those could be better adressed by either a debconf question, or by some examples better integrated.
Integration with other software, derivatives and custom distributions =====================================================================
While discussing how we could actually make it easier to setup relays, we got back to the lack of a way to source extra configuration files in `torrc`.
We outlined some benefits that would have a `/etc/tor/torrc.d` directory full of configuration snippets:
* The 'tor' package will not (or less) need patches to change the default settings. * It would make it much easier to implement example setups (relays, exit relays, bridges) either through a debconf question or through a system script like 'tor-setup-relay'. * Tails developers will only need to drop a very small extra configuration file instead of having to rewrite the whole, which should ease development and reviewing. * Other packages which need a hidden service to work (e.g. 'onioncat') would be able to create it automatically by installing the proper configuration snippet. That would enable them to work right after being installed.
Feature request: https://trac.torproject.org/projects/tor/ticket/2863
Control of the system-wide 'tor' daemon =======================================
We finally have (currently in 'experimental') an easy way for applications to control the system-wide 'tor' daemon: the ControlSocket option is on by default.
Vidalia, ARM and others now only require users to be in the system 'debian-tor' group to be able to control Tor.
We did not have the time to properly discuss if, and how, we offer an easy way to add users to this group.
Tor Browser Bundle (e.g tor-client) ===================================
There is an incentive to have something as close as the Tor Browser Bundle in Debian. Otherwise, desktop users on Debian get a smaller anonymity set (such strong partitioning already happened in the past, see http://bugs.debian.org/595375).
The main issue is the Tor fork of Firefox. There are a few possibilities on how it can be handled within Debian. Summary: this is doable, but requires a lot of work, and the cooperation of quite a few different parties.
One other thing that TBB is doing is to start its own instance of Tor. We agreed that it was a behaviour that would be quite desirable to have. It will make setup even more easier and it might limit users exposure when they are not using Tor.
In order to achieve that, we need either to make the 'tor' package not start Tor after being installed or we need a way have the `tor` binary without the rest of the daemon infrastructure (e.g initscript).
The former will probably be quite confusing to sysadmins, so we agreed on splitting out the daemon binary from the current 'tor' package to a new 'tor-bin' package.
How TorBrowser could get in Debian? ===================================
Having a full separate source package for TorBrowser is not possible due to Debian Policy 4.13. But there are still other options, all having their shortcomings:
1. Make the 'iceweasel' source package (that's how Firefox is called in Debian due to trademark issues) produce an extra 'tor-browser' binary package.
Issues:
- Mike Hommey (iceweasel maintainer) stated clearly that he did not want to maintain the Tor patches. But we can probably settle on a policy like "if it does not build, just drop it". The removal of a binary package does not trigger NEW queue processing. It is also not triggered if the same binary packages returns before two weeks. - Double (?) the build time of 'iceweasel' which is already huge. Security team will not be happy, and it's going to be harder to actually maintain the TorBrowser side of things.
Pros: until the patches do not apply anymore, it'll be less maintainance from our side.
2. Make the 'iceweasel' source package produce an extra binary package (e.g 'iceweasel-src') that will contain the full Iceweasel source. Create a 'tor-browser' package that Build-Depends on the former.
Issues:
- 'iceweasel' is a pretty fast moving target. This will need us to follow its uploads quite closely to ask for binNMU or to upload updated versions quickly. - The security team will have two packages to track instead of one. They might not like it at all.
Pros: much easier for Mike Hommey and we are autonomous to upload the 'tor-browser' package if changes are only needed there.
Looks like the latter is probably better. But it definitely needs to be checked with all parties involved first.
For browser extensions curretly shipped with TBB, Debian already has 'torbutton' and 'noscript'. But we miss 'httpseverwhere' (#591579) and 'betterprivacy'.
There are a few open issues that still need to be figured out: * TorBrowser should create dedicated profiles in the user home directories, * How can default values be set? Do we need 'locked down' preferences? * How should we handle other system-wide extensions? Active like for the main Iceweasel, totally ignored, or disabled by default? * If Debian ships the TorBrowser, should we prevent Torbutton from appearing in the usual Iceweasel?
This will require a lot of work for the initial bootstrap and a decent amount of work for the daily maintainance after that. But it looked worthwhile anyhow…
Cheers,