[tor-dev] A meta-package for Pluggable Transports?
andz at torproject.org
Thu Jun 30 21:09:01 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
On 06/30/2016 04:43 PM, Tom van der Woerdt wrote:
> 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.
I wouldn't worry for that at the moment as pluggable transports are
not being updated that often.
obfs4proxy - https://github.com/Yawning/obfs4/commits/master
fteproxy - https://github.com/kpdyer/fteproxy/commits/master
obfsproxy(2,3), scramblesuit -
> Questions that would need answering :
> * Is it acceptable to automatically install newer transports?
Installing newer pluggable transports doesn't mean that the tor bridge
configuration will need to immediately since changes will be needed to
the torrc, perhaps we could let the user decide by entering in a
ncurses menu and selecting the desired transport(s) and options for
each of them.
> * 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?
I think it's of highly importance to keep the older transports active,
so again we could let the user decide.
Additionally a user could set a selection and provide only
upgrades/changes bases on the select transport(s) and private/public
> * If it is not, how to we notify the user that they should renew
> their setup?
By using the ContactInfo of the bridge?
> * 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?
At this point it makes more sense to develop an install "recipe" in a
software deployment component with minimal dependencies such as Ansible.
We could aim to package the missing pluggable transports for most/all
distributions out there but this could take some significant amount of
time depending on the distribution's policies and package dependencies.
Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the tor-dev