On 7/24/15, Yawning Angel yawning@schwanenlied.me wrote:
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.
I think in all cases - a person should signal intent and we should automate things. A relay once required contacting Roger by hand - eventually it self-tested and now it is mostly automatic with one small stumbling block.
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.
I think it is orthogonal - we should be so lucky as to have too many relays that are awful in the network. That is not the core problem, I think. The core problem is that when someone wants to help, we don't make it frictionless - we load them with guilt about learning weird and sometimes obtuse stuff that is in my view unnecessary.
[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.
That is good to hear - I agree that some routers will probably not work. I think it would be great to get some numbers and other data on those failure modes.
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.
Ok. I understand.
[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).
To be clear - I think the library code is awful too. This is partially why I suggested we fork it and ship a fork. This is what the Vidalia GUI did - they just didn't do the NAT-PMP part of the task. Ironically, I think nearly no one every complained about that breaking their routers or anything horrible. I wonder if anyone uses that code anymore?
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'd like to say that I think informed consent here is good but also a strange thing. It feels like we should remember that Free Software comes with no warranty. That means that it may melt their home router or scare their cat. Hopefully it merely maps a port. :-)
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 I grok you now - the key thing I missed was the worry about flash proxies.
- 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).
Ok.
- 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 think you are right - I'd even advocate for a bit of go-seccomp - thus ensuring that the code is reasonably sandboxed. Along some MAC of some kind like AppArmor or SELinux or seatbelt, I can't imagine that you aren't perfect by comparison to the other library code.
- 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).
That sounds fine by me - I think that if that other stuff is done - it is easy to package it.
(And I think "apt-get upgrade tor tor-fw-helper", is a reasonable thing to ask of end users.)
I agree - we can easily package it for Debian - it could and should also be part of the other bundles we ship, I think. I guess I can package it for Debian - I'd like to take a look though before I commit.
- 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.
OK. Sounds reasonable.
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").
Ha. Understood.
- If this is deployed to users, they should know that historically a lot of routers have had hilariously broken/insecure uPnP implementations (Documentation issue).
Agreed.
- 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".
Seems reasonable.
I hope this clarifies things.
Completely. Thank you.
All the best, Jake