[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7822 [Pluggable transport]: Create an ezpt pluggable transports wrapper
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs