Re: [tor-dev] The Torouter project - where are we now?

[Jacob Appelbaum <jacob@xxxxxxxxxxxxx>]

On 04/21/2011 07:24 AM, Runa A. Sandvik wrote:
> On Thu, Apr 21, 2011 at 9:26 AM, Jacob Appelbaum <jacob@xxxxxxxxxxxxx> 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?

>>>
>>> #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@xxxxxxxxxxxxxxxxx
> 
> 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.

We can commit to a simple, fixed release cycle for the OS and a constant
stream of updates for Tor.

>>>
>>> #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.

> 
>>> #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):
>>>
>>> 1. 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?
>>
>>>
>>> 2. 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?

> 
>>> 3. 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?

> 
>>> 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?

All the best,
Jake
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev