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

[Nima Fatemi]

It’s currently difficult for bridge operators to keep up with the
changes in pluggable transports world. You’ve to be following tor
development and censorship-war very closely to know which transport is
needed currently and how to run them.

There are many people who are still running vanilla bridges thinking
they’re helping people in censored networks. Unfortunately those bridges
are not anyone any good while burning operator’s resources.

After some discussion on #tor-project a little while ago, the idea of
having a meta-package that includes all or the most recent transports
came up. Where people would install this meta package and it would
automatically take care of the required steps to get the latest
obfsproxy and set it up.

From a UX perspective, ideally you’d set up a bridge with small and
consistent steps like this:

$ sudo apt-get install tor-bridge
$ tor-bridge —-setup OR $ tor-bridge-setup

and then it will automatically get the most recommended PT (eg obfs4),
tor itself (if not installed), config your torrc, do a reachability
test, publish the bridge to bridgdb automatically and give you the
result in stdout:

# Congrats! your bridge is up and running on $port
# Your bridge is published in BridgeDB.
# Thanks for fighting censorship!

Additionally we can have more flags for different transports, ip, port
and so on. For example if you want to run obfs4proxy on an specific port
and not publish it, I imagine running something like this should get you
there:

$ tor-bridge-setup —-private —-obfs4 —-ip 1.2.3.4 —-port 5000

# Congrats! your bridge is up and running on port 5000
# You have chosen to not to publish your bridge. Users would need to
manually copy and paste the following line in their Tor Browser to use
your bridge.
#
# bridge obfs4 1.2.3.4:5000 C73ADBAC8ADFDBF0FC0F3F4E8091C0107D093716
cert=gEGKc5WN/bSjFa6UkG9hOcft1tuK+cV8hbZ0H6cqXiMPLqSbCh2Q3PHe5OOr6oMVORhoJA
iat-mode=0

The purpose of this email is to see whether this is a good approach (if
not, how can we improve it), and what is needed to move towards it.

Feedback from everyone, specially packagers and relay operators are
encouraged and welcome :)

Best,
-- 
Nima
0X58C4B928A3E218F6 | @mrphs

"I disapprove of what you say, but I will defend to the death your right
to say it" --Evelyn Beatrice Hall

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160630/f4eccfec/attachment.sig>