[tor-bugs] #7822 [Pluggable transport]: Create an ezpt pluggable transports wrapper

[Tor Bug Tracker & Wiki]

#7822: Create an ezpt pluggable transports wrapper
-------------------------------------+--------------------------
     Reporter:  dcf                  |      Owner:  asn
         Type:  project              |     Status:  needs_review
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:  easy
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+--------------------------

Comment (by asn):

 Replying to [comment:9 dcf]:
 > Replying to [comment:8 infinity0]:
 > > It was just more convenient to do so - we only had to create one
 single ~~class~~__file__ (well and some minor refactoring tweaks) rather
 than re-implement the whole SOCKS-ExtORPort handling and reactor/circuit
 setup stuff.
 > >
 > > Do you see a major advantage having a separate ezpt proxy? We could
 certainly do it, but it would take a bit more effort.
 >
 > Making it an obfsproxy module seems to be raising some design questions
 with awkward answers. An ezpt.spec file, for example, is quite different
 from the design in the ticket description (as I envisioned it, anyway),
 and so far the patch has a surprising lot of changes to obfsproxy itself.
 As it is, it's more "here's an easy way to create an obfsproxy module"
 than "here's an easy way to create a new pluggable transport." I'm not
 saying that's a bad thing, and it may actually be more useful in the long
 run.
 >
 > The need for SOCKS and ExtORPort support is a pretty important
 consideration. We should try to make those things part of pyptlib. I
 remember George and I talked about it--it wasn't so easy to do because you
 can't assume that programs will be using Twisted.
 >
 > Or maybe we should just recommend building on obfsproxy in general for
 Python pluggable transports? Use obfsproxy as the basic library, rather
 than pyptlib? It's what everyone will do anyway, because it's the easiest.
 It worked for ScrambleSuit; maybe it's a good idea in general?

 You raise some good points David.

 It's true that ezpt requires some awkward changes in the obfsproxy
 codebase that might not be useful for other pluggable transports. Still, I
 think that the required changes can be implemented in a way that are
 harmonious with the rest of the obfsproxy codebase. If we can't implement
 ezpt in a nice way, I don't want to merge ezpt in obfsproxy either (btw
 keep in mind that a good part of the changes in Ximin's branch were from
 #10342).

 I like the point you raise about recommending obfsproxy as the basic
 library instead of pyptlib. It's certainly worth considering, and in some
 sense it's what we are already doing (but we are not suggesting it loud
 enough). That is, if someone develops a plugin for obfsproxy that screws
 the whole codebase, we won't merge it in the mainline obfsproxy but we can
 keep it as a separate transport. This happened in the old obfsproxy with
 stegotorus. Stegotorus required too many extra functions from obfsproxy,
 so they ended up forking it.

 However, if we end up suggesting obfsproxy as a library that people can
 use and modify to build their pluggable transport, we can certainly modify
 obfsproxy to better facilitate this need. That is, make obfsproxy a
 program that people use to develop a single pluggable transport, instead
 of the pluggable transport suite that it currently is. Of course, I'm not
 sure if this task is worth prioritizing right now.

 (FWIW, Scramblesuit's code is going to be incorporated into the obfsproxy
 codebase in the future. It's changes are simple enough and they fit with
 the general obfsproxy architecture.)

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