[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 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs