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@xxxxxxxxxx : :â : # apt-get install anarchism
`. `'`
`-
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev