[tor-dev] A meta-package for Pluggable Transports?

[Vasilis]

-----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
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXdYpqAAoJEF+/cLHRJgFivcUQALECYAr+EK78LP/DvLz26A+e
8Is1A5g+75iAWu/jO+V1kcOL6vg+s5hSFvbOQTN9xLEdLJdN/bO+IAO+VVem8FfQ
mRuYQpE9kMEfhNx5bgP1r4e2AEovoPKAyEzZ9tEOZn+YzJar6C6CpOW6czXZistl
OIaDrNp1qQx2ybFYq2400Ldgcb/gT0YSP5rowbP68tSz05og2BdUtTTlltRHcD2n
BUvGvO8tkGBWs0KZohmc9KYZZOiDIquQG6LCTkct+J0VdkjAWHyv7bHW8MbnXRtm
Z7uidwR0hC4vdix5iKtnEhQBh5gZu5BBbH9m3rw/FS3Un4kgArQWjBBhivYLIgF1
Tgk90E24nRPbByks7zTq33wD11WW6WjB84Wn9uGVLq6v7UP43Qe7RCZlresYO80+
FB5zohiJFh5qGB7fCILQt+23TwaJaKTB+lGPj3QHgaoXiWHkmlJ9h9r81S3TwM/E
ZfeeqdHwb0CawsujRjqoVLRVUik7svYDj/5yakMBralsFt0IbfnyUhF+J7EIUDmz
TzStxhMOnzZukNl/Er/XLJsPgJcRXV7/OcecbAJjs9etJMSKfbiu4coGezWnLfqD
ZUmTupfx+4qQU0yuTIyHPhlyQD72e6DRLJdpQ6U6NDbX7NW//2Kcn8pEdH9yAvqh
eJCnVn5nzx3Qb/cEANO5
=aMFT
-----END PGP SIGNATURE-----