On Fri, 24 Jul 2015 16:21:31 +0000 Jacob Appelbaum jacob@appelbaum.net wrote: [snip]
At this point with all the resources available, I will guess that if the user needs something like tor-fw-helper, they probably have no idea what router firmware is.
Right - but why should they need to know? The goal here is to run say, a private bridge for their own use - should we really keep the status-quo that is a nightmare to setup?
I have less objections towards people using tor-fw-helper for bridges than for something like flashproxy or full fledged relays.
Full fledged relays because of stuff like: https://tor.stackexchange.com/questions/7164/why-do-relays-not-end-idle-tcp-...
IMO similar to relays with insufficient bandwidth, relays that can't connect to any other relay on demand as required (due to a full NAT table) do bad things to network health. This is probably an orthogonal discussion though.
[snip]
And again, no. If they need tor-fw-helper, I doubt they know what firmware is in the first place.
Right and yet, if they have it, they still have to go through another step: using it. I suspect that of our users, we will have zero who use it by default; some will choose to use it - this is the really hard stumbling point at the moment. Anyone who wants to use it has to compile it from source and jump through a lot of hoops before they've even tested it against their home router.
Unless their router is *extremely* quirky, the new code will work. Pain will start happening if you add lots and lots of mappings depending on how your router behaves when the uPnP table gets full (since I have to request infinite duration leases). NAT-PMP should basically always work.
Again, this is more a flashproxy issue (since the mapping ideally only lasts for as long as the Tor Browser session is active) than a relay one, and we'd want to select a random port at runtime.
[snip]
Is anyone from support reading this email thread, I wonder? I've cc'ed Colin - perhaps he can chime in about supporting a possible usage.
I think that the primary reason we did not ship tor-fw-helper was to punt on the fact that we think the code quality for the *client* libraries was awful. That is not the case with your Go implementation. Thus, I think we should consider how to either solve the tor-fw-helper code (eg: sandbox with seccomp, AppArmor?) or if it is removed, I hope we won't take two steps backward by making it even more difficult to run a relay, even if a user is perfectly informed and perfectly aware of the hubbub around NAT-PMP and UPnP.
Right. The primary concern when I started my rewrite was the libraries are really scary (since we were linking against stuff that is part of the problem on the router end, that make me nervous).
If a user is fully informed about the hazards surrounding uPnP then the new code is probably a fine replacement (It even has a few extra goodies that the original doesn't, like dumping the mapping table, and support for removing mappings).
I hope I've made my point clear: I really want to see a helper in-tree or shipped to end users - even if it isn't *used* by default. I put a lot of effort into it once. I can't express enough how demoralizing it is that this code has basically never been used and may soon infact be rm'ed entirely rather than deployed. Even if it isn't the stuff I helped to write, I hope we work to solve this problem for user and not to punt - that was always the goal.
Indeed. The rewrite wasn't exactly easy either. I think I've done a poor job of communicating my position, so I'll try to summarize it.
* I think the new code will work for most people for running a private bridge, or relay (though the latter with a consumer grade router may be a bad thing for network health).
* I think the new code is safer than the old code, because it doesn't link against 3rd party libraries with "questionable" code quality, and is in a memory safe language. YMMV there.
* I still intend to move the new code from github.com to git.tp.o, and am willing to provide things like signed release tags, and tarballs of releases if that will make packaging it easier, but I won't be the one making packages (unless I happen to get bored enough to put it in AUR).
(And I think "apt-get upgrade tor tor-fw-helper", is a reasonable thing to ask of end users.)
* I have reservations about deploying it as part of Tor Browser for use with flashproxy due to poor router side code. Ultimately this is the support team's call, and if they're ok with it, I will do the integration work here.
Most of the really broken (non-security) behavior only happens when the uPnP table starts to get full, which is presumably not a concern for the bridge/relay use case (Since like aliens from the planet Zeist, "There can be only one").
* If this is deployed to users, they should know that historically a lot of routers have had hilariously broken/insecure uPnP implementations (Documentation issue).
* As far as support/bugfixes/maintenance from my end, there's a limit to what I can do for quirky/broken routers, and in a lot of cases this will end up as "patches accepted".
I hope this clarifies things.
Regards,