[tor-dev] obfsproxy dns transport

[David Fifield]

On Wed, Feb 19, 2014 at 04:59:05PM -0800, George Kadianakis wrote:
> > George Kadianakis:
> >> b) You can write your own Python code and selectively steal code from
> >>    obfsproxy. You will have to steal the code that does networking,
> >>    Extended ORPort, environment variable parsing (pyptlib), SOCKS,
> >>    etc. This might not be too hard.
> >
> > Could the shared code be used to augment pyptlib? I guess Extended
> > ORPort is probably something that all Python pluggable transport
> > implementations might want.
> 
> The issue is that by adding an Extended ORPort implementation in pyptlib
> we would have to select a specific networking library (socket, Twisted,
> etc.) and the transport author would be forced to use the same networking
> library.

It's not so clear what the best way to handle it is. We thought about it
in the past but didn't come to a clear solution.

If any kind of ExtORPort support is added to pyptlib, I think it makes
sense for it to be a Twisted one, because that's what people seem to
want to use.

The act of creating a new transport program separate from obfsproxy,
that steals as much code from obfsproxy as it needs, could be a good way
to identify what ExtORPort functions need to be present in a library and
how they need to be generalized. I think it would not be a waste of
effort to make a new program with this goal in mind.

golang gets to cheat on the issue because there's really only one way to
do concurrent networking in Go. (But also, nobody has used goptlib as
much as I have, so it might not be as clear-cut as I think.)

David Fifield