On Thu, Apr 21, 2011 at 5:17 PM, Jacob Appelbaum <[email protected]> wrote: > On 04/21/2011 07:24 AM, Runa A. Sandvik wrote: >> On Thu, Apr 21, 2011 at 9:26 AM, Jacob Appelbaum <[email protected]> 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 [email protected] >> >> 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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
