[tor-bugs] #9445 [Tor Launcher]: Include support for Pluggable Transports

[Tor Bug Tracker & Wiki]

#9445: Include support for Pluggable Transports
---------------------------------------------------+------------------------
 Reporter:  bastik                                 |          Owner:  brade
     Type:  task                                   |         Status:  new  
 Priority:  major                                  |      Milestone:       
Component:  Tor Launcher                           |        Version:       
 Keywords:  tbb-3.0-stable-blocker, tbb-usability  |         Parent:  #9444
   Points:                                         |   Actualpoints:       
---------------------------------------------------+------------------------

Comment(by isis):

 Replying to [comment:5 mikeperry]:
 > I think the answer here is to make the bridge input to Tor Launcher
 input format checking more relaxed, and take bridge lines directly from
 bridgedb and set them in the torrc/via SETCONF, perhaps verifying only
 that they start with 'bridge'.
 >

 BridgeDB recently removed the `"bridge "` prefix from both regular bridge
 lines
 ([https://gitweb.torproject.org/user/isis/bridgedb.git/commit/792cfd99bb3a4d5a116202e76532232aba6e6312
 commit]) and pluggable transport lines
 ([https://gitweb.torproject.org/user/isis/bridgedb.git/commit/20d6171844d275f768229a1a4052a31fd42cd4bd
 commit]), because PT-bundle users tried to put the lines directly into
 Vidalia, which glitched out on it (#9156).

 BridgeDB can return whatever format you like, as long as it is specified.

 > I would also like to have the ability to support identity fingerprints
 and any other pluggable transport-related key material for bridge users
 (#9499).
 >

 It can also return ID fingerprints, there is code for this already though
 I haven't tested it.

 The `[arglist]` portion of an extra-info descriptor `transport` string is
 somewhat problematic, with
 [https://gitweb.torproject.org/torspec.git/commit/a01bb8e8e285d644c2e59c0ea788e45bf37470f4
 the current way that it is specified] -- though it does make sense to be
 spec'd this way. Basically, '''tor does no sanitisation of the `transport`
 line `[arglist]`''' for a pluggable transport sending args, because it is
 within the treat model to assume that the transport is a trusted
 application.

 However, '''this puts all the responsibility of parsing on BridgeDB'''.
 Which is also fine, and much more doable in Python than in C...it's just
 that '''writers of pluggable transports which they would like to see
 deployed need to create a spec, and need to create a ticket for BridgeDB
 that points to the spec and says exactly what BridgeDB should parse
 for.''' An example of a ticket which does ''not'' help me understand what
 to parse for is a vague "BridgeDB should pass pluggable transport shared-
 secrets to clients" (#9013) ticket.

 > I don't think this should be too hard, and if we ship a set of pluggable
 transports, it will make #9156 and all of the pluggable transport
 integration stuff easier to develop and test. I think this should be a
 high priority as a result.

 Agreed.

 '''@mikeperry:''' Are you thinking of making two separate sets of bundles
 again, like in the TBB-2.x series? Because now that we've lost all the QT
 junk, we could probably fit a Python interpreter and the deployed PTs in
 there, and then we wouldn't have to deal with users not knowing the
 difference between the two bundles.

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