Re: [tor-bugs] #16756 [Pluggable transport]: Formalize and document what it takes for a PT to get deployed.

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#16756: Formalize and document what it takes for a PT to get deployed.
-------------------------------------+----------------------
     Reporter:  yawning              |      Owner:  yawning
         Type:  task                 |     Status:  new
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:  SponsorS
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+----------------------

Comment (by dcf):

 Replying to [comment:5 mikeperry]:
 > I am deeply wary of the fast-and-loose flashproxy model for lots of
 reasons. If the introducer can't manage to authenticate itself, and it
 can't tell you how to authenticate your traffic to the flashproxy bridges
 it gives you, then long-term I am against it and anything that behaves
 like it. In fact, I would be in favor of killing it until we can fix these
 issues, especially if we're thinking of trimming down the supported PT
 list anyway. I really, really don't want a future WebRTC-based version of
 flashproxy to end up as such an unauthenticated free-for-all mess, for
 example.

 I'm fine with removing flashproxy from the bundle.

 Mike, the JavaScript flash proxies are just dumb pipes to the Tor bridge.
 They don't have an identity that is separately authenticated. You still
 authenticate the Tor bridge, as long as you have a fingerprint on the
 bridge line (which we do now).

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16756#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs