[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 infinity0):

 Replying to [comment:15 dcf]:
 > I worry a bit that the objective drifted to "implement a stdin–stdout
 filter at all costs" from "implement an easy way to prototype transports."
 I feel like this is a transport that would have been good to first
 prototype as a shell script. Maybe ezpt would be a good application of
 goptlib? It has the SOCKS and extorport stuff you need. It would probably
 be only 100 lines on top of each of the example plugins.
 >

 It may be the case that some future transports will be implemented as
 stdin-stdout filters - I don't see anything inherently wrong with that. PT
 authors might even prefer it, if it suits their model, and if the PT
 interface changes, they don't need to do anything, just wait for ezpt to
 update.

 > I don't think we should encourage the use of commands like tr, nor even
 mention the possibility in documentation. It's probably not safe to expose
 random commands to the network.
 >
 > I don't think ezpt should make itself responsible for the buffering of
 its subprocesses; i.e., I think the stdbuf stuff should be removed. I
 understand the reason for it. But this is a
 [http://perldoc.perl.org/perlipc.html#Bidirectional-Communication-with-
 Another-Process well-known problem] ("buffering is really going to ruin
 your day") with a lot of workarounds--we shouldn't codify just one of them
 without at least an examination of the alternatives. People can always
 stdbuf their own commands if that works for them. This also ties in with
 not plugging unsuspecting programs to ezpt.
 >

 I'm not sure how you can give secure-yet-simple examples for ezpt. We can
 definitely mention that the examples should not be used in production,
 though.

 stdbuf isn't enabled by default, the user has to ask for it. It's a
 documented option, but we could remove this option as long as we still
 document the issue and workarounds very visibly and obviously. (And make
 sure future maintainers don't remove this as "indirect trivia"). It might
 be well-known if you have specific background knowledge, but we can't
 expect PT authors in general to know about it. (It blocked both George and
 I on the day we started coding, and it took me several more hours on a
 different day, questions in 2 IRC channels and about 6 people theorising,
 only some of which was correct, to figure it out properly.)

 > I also tend to think that there's no reason to try and get multiple
 transports running in the same process. Process isolation exists for a
 reason, and it works really well. Personally I would want each separate
 ezpt to be in a separate process, for better robustness. Running in one
 process is fine too, but I don't think we should compromise anything else
 to make it possible.
 >

 This is more of an issue with the PT spec - managed mode implies multiple
 transports running in the same process. But architecturally, I can see
 that it would be nicer to have ezpt be a separate process. Also, the
 advertised purpose of obfsproxy is a bit different from what we want to do
 with ezpt.

 So yes, I do sympathise with the intention to have ezpt be a separate PT
 of its own. I've been meaning to get more into Go, so perhaps I'll try to
 re-do this with goptlib at some point.

 But I also don't want to see this work go to waste, so I will get it into
 a merge-ready state at least, and we could either merge it but not
 announce it, or keep it in a separate branch for future PT authors to play
 with.

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