[tor-dev] fteproxy depends on obfsproxy...

[Kevin P Dyer]

I think we should (1) make pyptlib easier to use but (2) wait until the new
PT spec. is settled upon.

Let's pick this back up when the spec. is complete.

-Kevin

On Tue, Sep 8, 2015 at 5:56 PM, isis <isis at torproject.org> wrote:

> George Kadianakis transcribed 1.4K bytes:
> > Kevin P Dyer <kpdyer at gmail.com> writes:
> >
> > > ...and it shouldn't.
> > >
> > > Fortunately, the dependency is isolated to a single file. See [1].
> > >
> > > My understanding is that pyptlib [2] is no longer maintained.
> > >
> > > wiley/asn/etc. - What's the proper way to remove this dependency, but
> make
> > > it easy for fteproxy to be a PT?
> > >
> > > -Kevin
> > >
> >
> > Hmmm, a plausible way to remove this dependency would be to rewrite the
> > obfsproxy networking logic that you use into pyptlib (or even fteproxy).
> >
> > That said, are you currently experiencing an issue that made you bring
> up this topic?
> > Because AFAIK pyptlib and obfsproxy are not currently suffering from any
> serious bugs.
> >
> > Even though no new PTs are being developed for obfsproxy, I think any
> serious
> > bugs on obfsproxy would be taken care of by a combination of me, Yawning
> and the
> > rest of the Tor hivemind. Same goes for pyptlib IMO.
> >
> > However, I understand that carrying the weight of the whole obfsproxy
> codebase
> > just for the networking logic might be a bit too much. Are there any
> systems
> > apart from Tor that are using the fteproxy+obfsproxy combination? If
> yes, and it
> > gives them pain, maybe it indeed makes sense to go through the
> engineering
> > hurdle of decoupling the obfsproxy networking logic and plugging it into
> > fteproxy...
> >
> > Or is there another reason that I'm missing here?
> >
> > Cheers!
>
> Even if there are fewer users (and none outside Tor AFAIK), it might make
> sense
> to view the refactoring as necessary for making pyptlib easier/friendlier
> to
> use?  And even if many transports have moved to Golang, but I think it is
> still
> in general a nice thing to do for the rest of the world to maintain a
> usable
> Python PT library.
>
> If help is wanted decoupling the networking bits and putting them into
> pyptlib,
> I'd gladly assist.
>
> Although perhaps this should wait until the PT spec is refactored so that
> we
> don't have to refactor pyptlib twice.
>
> --
>  ♥Ⓐ isis agora lovecruft
> _________________________________________________________
> OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
> Current Keys: https://blog.patternsinthevoid.net/isis.txt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150909/325c2532/attachment.html>