<div dir="ltr">I think we should (1) make pyptlib easier to use but (2) wait until the new PT spec. is settled upon.<div><br></div><div>Let's pick this back up when the spec. is complete.<br><div><br></div><div>-Kevin</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 5:56 PM, isis <span dir="ltr"><<a href="mailto:isis@torproject.org" target="_blank">isis@torproject.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">George Kadianakis transcribed 1.4K bytes:<br>
<div><div class="h5">> Kevin P Dyer <<a href="mailto:kpdyer@gmail.com">kpdyer@gmail.com</a>> writes:<br>
><br>
> > ...and it shouldn't.<br>
> ><br>
> > Fortunately, the dependency is isolated to a single file. See [1].<br>
> ><br>
> > My understanding is that pyptlib [2] is no longer maintained.<br>
> ><br>
> > wiley/asn/etc. - What's the proper way to remove this dependency, but make<br>
> > it easy for fteproxy to be a PT?<br>
> ><br>
> > -Kevin<br>
> ><br>
><br>
> Hmmm, a plausible way to remove this dependency would be to rewrite the<br>
> obfsproxy networking logic that you use into pyptlib (or even fteproxy).<br>
><br>
> That said, are you currently experiencing an issue that made you bring up this topic?<br>
> Because AFAIK pyptlib and obfsproxy are not currently suffering from any serious bugs.<br>
><br>
> Even though no new PTs are being developed for obfsproxy, I think any serious<br>
> bugs on obfsproxy would be taken care of by a combination of me, Yawning and the<br>
> rest of the Tor hivemind. Same goes for pyptlib IMO.<br>
><br>
> However, I understand that carrying the weight of the whole obfsproxy codebase<br>
> just for the networking logic might be a bit too much. Are there any systems<br>
> apart from Tor that are using the fteproxy+obfsproxy combination? If yes, and it<br>
> gives them pain, maybe it indeed makes sense to go through the engineering<br>
> hurdle of decoupling the obfsproxy networking logic and plugging it into<br>
> fteproxy...<br>
><br>
> Or is there another reason that I'm missing here?<br>
><br>
> Cheers!<br>
<br>
</div></div>Even if there are fewer users (and none outside Tor AFAIK), it might make sense<br>
to view the refactoring as necessary for making pyptlib easier/friendlier to<br>
use?  And even if many transports have moved to Golang, but I think it is still<br>
in general a nice thing to do for the rest of the world to maintain a usable<br>
Python PT library.<br>
<br>
If help is wanted decoupling the networking bits and putting them into pyptlib,<br>
I'd gladly assist.<br>
<br>
Although perhaps this should wait until the PT spec is refactored so that we<br>
don't have to refactor pyptlib twice.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
 ♥Ⓐ isis agora lovecruft<br>
_________________________________________________________<br>
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35<br>
Current Keys: <a href="https://blog.patternsinthevoid.net/isis.txt" rel="noreferrer" target="_blank">https://blog.patternsinthevoid.net/isis.txt</a><br>
</font></span></blockquote></div><br></div>