Op 30/06/16 om 21:31 schreef Nima Fatemi:
Tom van der Woerdt:
How about a conf.d style folder that plugins like bridges can drop files in?
$ yum install -y obfs4proxy ... $ cat /etc/tor/torrc.d/obfs4.conf ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy managed ServerTransportListenAddr obfs4 0.0.0.0:9013 ServerTransportListenAddr obfs4 0.0.0.0:9014 $ systemctl restart tor
In this case you'd still have to know what obfs4proxy is or when and where to get it. It doesn't solve the problem of the need to catch up with censorship and tor development. And to break a news for you... obfs5 is coming soon. What are we gonna do when that comes out? What do we call the package? This also doesn't help running any other transports like meek.
Best,
Oops, should probably have elaborated a bit more.
You can combine conf.d with the meta-package. For example, when you run "yum install tor tor-bridge" the tor-bridge package could bring in obfs4proxy with it and automatically configure that : $ yum install -y tor tor-bridge $ systemctl start tor
--------------
The challenge, imho, is figuring out how to handle upgrades. A virtual package like the tor-bridge in my example would automatically pull in obfs5proxy, leaving obfs4proxy intact, but this may be considered bad behavior to the user, as it may also need firewall changes etc.
Questions that would need answering :
* Is it acceptable to automatically install newer transports? * If it is, should we automatically deprecate the older transports? And in that case, can we maybe just replace the old transport with the new one while reusing the port? Will that break UX for the user who actually set it up, as it now has a different type of proxy on the same port? * If it is not, how to we notify the user that they should renew their setup? * Most users don't compile Tor from scratch, but use packages that come with distributions such as Ubuntu, Debian and CentOS. How do you properly integrate with those?
Tom