On Thu, Apr 21, 2011 at 9:26 AM, Jacob Appelbaum jacob@appelbaum.net wrote:
On 04/19/2011 03:17 AM, Runa A. Sandvik wrote:
Hi everyone,
I am trying to figure out how we can move the Torouter project forward. In this email, I will try to summarize the current status of this project.
The Torouter project has a total of four bugs in Trac. These are #2334, #2376, #2370 and #2596.
#2334: Torouter on Buffalo breaks with large cached-descriptors[.new] files. The quick and easy solution here is to attach a USB stick to the router and use it as Tor's data directory. However, it would be great if someone could take a look at this and figure out a way to solve it.
This is only a problem on smaller hardware - so if we really want the Buffalo router, we'll need to fix this or create a work around that isn't a total PITA. For now, I think we can just add a USB disk and deal with it later.
If we find that the router can't handle being a bridge, I'm not really concerned with this bug.
As far as I know, the router can handle being a bridge as long as it has enough disk space.
#2376: Torouter on OpenWrt shouldn't have its data directory in /tmp/. The problem with having Tor's data directory in /tmp is that whenever Torouter is rebooted, Tor generates new keys and gets a new fingerprint.
I commented on the bug - it's easy enough to change this by submitting a patch to openwrt-devel@lists.openwrt.org
Great.
There are a couple of different ways to solve this problem; Karsten suggested that we could modify OpenWrt to stop creating a /tmp partition. This probably means that we will have to ship our own OpenWrt image. I'm thinking that another option would be to modify the Tor-OpenWrt-package to use / as the data directory instead of /tmp. However, I wonder if 64M (no matter how it's partitioned) of space on the Buffalo router is insufficient as long as #2334 remains open.
If we're shipping our own image, we can do a bunch of stuff. Is that what we want to do?
I don't think we should ship our own image, for the simple reason that we already have enough stuff to maintain.
#2370: Torouter basic Web UI for OpenWrt. I haven't tried the web interface myself, but development seems to be moving along nicely. I'm not sure what the remaining steps are, other than packaging it as tor-ui (or similar) for OpenWrt.
The web interface should go into version control, it should be added to the tor-alpha package in the OpenWRT svn (that's why I created it), and it should be used by some people.
Ok, do you want to take care of this? That is, putting the web interface into version control and packaging it for OpenWrt.
#2596: Figure out a better name than "torouter". Andrew thinks we should come up with a better name for this project, one that does not have "Tor" in the name. Suggestions?
I think torouter is a perfectly fine name until we actually have a shipping prototype.
Sure, that works too.
The Torouter project also has some open questions (some are mentioned on https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/Torouter as well):
- How can we make sure that the version of Tor in OpenWrt is always
up to date? Should we set up our own OpenWrt repository? Right now, the version of Tor in OpenWrt is 0.2.1.26. Also, should we offer packages for both stable and unstable?
I think we should contribute back to OpenWRT (as I've been doing) and for our router, we should consider adding a feed for the specific hardware we intend to support. Still, we'll need to ensure the versions of _everything_ are up to date and not just Tor.
So what's our general update strategy for any platform we ship?
- We want to collect statistics, which means that we need to ship a
GeoIP file as well. I'm thinking we should create a tor-geoipdb package for OpenWrt. Thoughts?
There's a tor-geoip package created by the tor package in the OpenWRT svn repo (from looking at the Makefile).
So, it turns out that packages in OpenWrt are not updated after a release. That explains why I got 0.2.1.26 when 0.2.1.30 is available in the OpenWrt SVN.
The best way to ensure that users can easily upgrade Tor and related packages is to set up a torproject.org repository for OpenWrt packages. This repository would then have to be added to /etc/opkg.conf.
- Do we want one Tor process for bridging and one for the transparent
wifi network? I think this sounds good, if the router can handle it. If not, then just running a bridge is ok too.
I think we should run both in a single Tor for now but I think we should only enable the bridge by default. The web UI can enable the transparent stuff if we want it.
Sounds good.
Have I missed anything important? Are there any other packages that we should include in OpenWrt? Other comments or suggestions? If you have more information or would like to help out, please let me know.
We need to make packages for the libnatpmp and miniupnpc libraries because we need tor-fw-helper support in tor-alpha.
Is this something you can / want to take care of?