-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
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. Commit logs: obfs4proxy - https://github.com/Yawning/obfs4/commits/master fteproxy - https://github.com/kpdyer/fteproxy/commits/master obfsproxy(2,3), scramblesuit - https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/log/obf sproxy/transports
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 visibility.
- 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.
~Vasilis - -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162