===========================
The Tor ecosystem in Debian
===========================

New upstream packaging policy
=============================

The Tor project would like to change the way it packages its main
software.

For <https://svn.torproject.org/svn/projects/roadmaps/proposed-package-roadmap.txt>

    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.

Q: Do we want to implement those changes in Debian?
Q: Which upgrade paths do we want?

tor-relay / tor-exit-relay / tor-bridge
=======================================

Possible answer:

 1. Move tor binary to a tor-bin package.
 2. Leave tor with the current generic configuration file, depends on tor-bin
 3. Create tor-relay, tor-exit-relay and tor-bridge, all depending on tor-bin,
    with a dedicated default configuration file and a dedicated init script

tor-client
==========

Q: How could we implement an equivalent of the Tor browser bundle in
   Debian?
Q: Upstream has decided to fork Firefox into TorBrowser. What should
   we do about it?

With FF5, upstream is finally getting rid of privoxy/polipo.

Make tor-client depend on tor-bin + vidalia + iceweasel + xul-ext-torbutton?
Creating a specific profile?

Current relevant patches in TBB :

 * 0001-Firefox5-Block-Components.interfaces-lookupMethod-fr.patch:
   Javascript fingerprinting issue. Looks like upstream is acknowledging the
   issue. Might be accepted by glandium in main iceweasel.
 * 0002-Firefox5-Make-Intermediate-Cert-Store-memory-only.patch:
   Make Intermediate Cert Store memory-only. Complicated, not really nice.
 * 0003-Firefox5-Make-Permissions-Manager-memory-only.patch:
   Pretty straightforward. Fully dependent on the proper preference. Might be
   accepted by glandium.

What we can propose to Mike Hommey:

 1. Create a second binary package out of the iceweasel source that would
    build an equivalent to TorBrowser.
 2. If the Tor patches lag behind, he can simply comment out that second
    binary package.
    (NEW queue processing would is not triggered when a package is removed.
    It is also not trigerred if a binary package is added back before
    two weeks.)

Extensions :

 * torbutton.xpi → xul-ext-torbutton
 * noscript.xpi → xul-ext-noscript
 * httpseverywhere.xpi → bugs.debian.org/591579
 * betterprivacy.xpi → unrelevant (flash cookies)

Open question:
 * does it need a specific profile?
 * how should we set default values?
 * make xul-ext-torbutton NOT active by default on all browsers?

Open question: how to make a dedicated profile?

 * http://kb.mozillazine.org/Locking_preferences
 * FireFox command line options:
   + -profile "/path/to/profile"

     Start with a profile with the given path. Firefox, Thunderbird and SeaMonkey2.x only.

   + -override /path/to/override.ini

     Load the specified override.ini file to override application.ini (
     browser/app/application.ini). This can be used to suppress the Migration Wizard
     at startup by loading the following override.ini. Firefox only.

     [XRE]
     EnableProfileMigrator=0

Vidalia, ControlSockets and debian-tor group
============================================

Vidalia now has a postinst script that automatically adds users to the
debian-tor group using a debconf question.

Q: Do we really want to do that?
Q: At which priority should be asked the question?