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

 Replying to [comment:13 asn]:
 > OK. I did a code review.
 >
 > The code looks OK and I don't think it screws up with obfsproxy
 internals that much.
 >
 > I think I'd be up for merging this now, and potentially remove it in the
 future if we make a dedicated ezpt program. David what do you think?

 You should merge it if you think it makes sense. You should ask: How do
 you see it being used as implemented?

 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.

 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 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.

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