[tor-bugs] #7153 [Pluggable transport]: Don't require pluggable transport proxies to be SOCKS proxies

[Tor Bug Tracker & Wiki]

#7153: Don't require pluggable transport proxies to be SOCKS proxies
---------------------------------+------------------------------------------
 Reporter:  karsten              |          Owner:  asn
     Type:  project              |         Status:  new
 Priority:  normal               |      Milestone:     
Component:  Pluggable transport  |        Version:     
 Keywords:  SponsorF20130228     |         Parent:     
   Points:                       |   Actualpoints:     
---------------------------------+------------------------------------------

Comment(by dcf):

 Replying to [comment:16 nickm]:
 > Okay, so here's my suggestions for trying to make everybody a bit more
 happy here.  If people like this, I'll turn it into a proposal and a set
 of tickets.
 >
 > === Nick's Proposal, v1 ===
 >  * Extract variant of the easy parts of Proposal 199, so that pluggable
 transports can also act as bridge managers.  The parts I propose to build
 are:
 >     * When being launched, a managed proxy can find out a tor controller
 port, along with a password or cookie location to use to authenticate to
 Tor. An external proxy can get this information too.  Getting this
 information means that you're acting as a bridge manager.
 >     * After making a controller connection to Tor, the bridge managers
 can use SETCONF to tell Tor about bridge information.
 >  * Change the semantics of setting "UseBridges 1" when no bridges are
 configured.  Right now, it's an error. I propose that instead it have the
 same effect as
 >  * Add a new `__Bridge` configuration option. It will have the same
 effect as Bridge, but (because it starts with `__`) its values won't be
 saved by a SAVECONF command.
 >  * Add a new ADDCONF / DELCONF command to help maintain the Bridges and
 `__Bridges` configuration options. It will only operate on a linelist.
 DELCONF will only remove lines when they're provided verbatim.
 >  * Clarify that it's okay to be a proxy that only supports SOCKS4a, so
 that nobody goes out of their way to build SOCKS5 support when they don't
 need to.
 >  * Add a new SOCKS reply code meaning "proxy not ready yet; try later."
 >  * Let's add a weight parameter to bridges.

 What you describe sounds like it will work for flash proxy.

 I guess there is a tension with #5018--ideally we want the `flashproxy-
 client` transport plugin to start without having to configure any false
 bridges. We currently use the "fake" address 0.0.1.0:1, but it's not for
 the sake of getting the transport to start up--it's because we don't know
 any real bridge addresses at startup time.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7153#comment:17>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online