On Thu, Apr 21, 2011 at 5:17 PM, Jacob Appelbaum jacob@appelbaum.net wrote:
On 04/21/2011 07:24 AM, Runa A. Sandvik wrote:
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.
What tests indicate this? How many clients can it handle and at what rate?
My mistake. I thought someone had a bridge running and that the only problem was disk space. I'll see if I can set up my router as a bridge this weekend and get things working.
#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.
I generally agree but I think we're going to have to deal with this issue one way or another.
If we're shipping people a router, I'd like to harden it. For example - it does not appear that all of the gcc hardening features are enabled by default.
Are you talking about hardening Tor or OpenWrt? Or both?
We can commit to a simple, fixed release cycle for the OS and a constant stream of updates for Tor.
Sure, that would work. I believe users will have to re-flash their routers to install a new image, though. Or maybe there's a nice way to handle upgrades in OpenWrt?
#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.
Not really? :-)
In an ideal world, I think we should make these changes in the tor-alpha package. Currently, I'm not familiar with the webui at all.
I'd prefer that someone involved in developing the webui actually built a stand alone package.
I've sent Daniel an email asking if he wants to package the GUI.
#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.
Makes sense.
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.
That's similar to what I said on IRC; it seems reasonable to keep the Tor package updated in OpenWRT. We need to decide if we want to build regular packages for installation and also if we want to host them. I think this is mostly an Erinn question - helix?
- 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.
What's the default config that we want to ship?
I was thinking about a config similar to the one in the bridge-by-default bundle.
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?
I'm a little more interested in making these packages. Do you want to open a set of bugs and we can continue deeper discussion in bugs?
Sure, I can do that.