[tor-dev] Report from the "Tor ecosystem" BoF at DebConf 11

Thu Jul 28 22:42:15 UTC 2011

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,
-- 
Jérémy Bobbio                        .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110729/9b273a3d/attachment.pgp>