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

["Runa A. Sandvik" <runa.sandvik@xxxxxxxxx>]

On Thu, Apr 21, 2011 at 5:17 PM, Jacob Appelbaum <jacob@xxxxxxxxxxxxx> wrote:
> 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?

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

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

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.

-- 
Runa A. Sandvik
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev