...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
[1] https://github.com/kpdyer/fteproxy/blob/master/fteproxy/cli.py#L248 [2] https://pypi.python.org/pypi/pyptlib
On Mon, 7 Sep 2015 14:37:07 -0700 Kevin P Dyer kpdyer@gmail.com wrote:
...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.
It isn't? It hasn't gotten any updates because nothing broke and the pt spec is relatively static (for now, eventually it'll change and pyptlib will get a flurry of updates as needed).
wiley/asn/etc. - What's the proper way to remove this dependency, but make it easy for fteproxy to be a PT?
There isn't an easy way beyond "reimplementing all the functionality currently provided by obfsproxy". It probably won't be overly hard to do but implementing yet another socks 5 server is likely to be tedious and annoying.
Regards,
Response inline.
On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel yawning@schwanenlied.me wrote:
On Mon, 7 Sep 2015 14:37:07 -0700 Kevin P Dyer kpdyer@gmail.com wrote:
...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.
It isn't? It hasn't gotten any updates because nothing broke and the pt spec is relatively static (for now, eventually it'll change and pyptlib will get a flurry of updates as needed).
I was speaking to Brandon Wiley about this last week. I don't want to speak for him, but I remember him saying that it's no longer being developed.
Either way, does pyptlib help solve this issue?
-Kevin
The background: I've been trying to get the fteproxy package into debian. In the code review process, the dependency on obfsproxy was flagged as a not-so-great thing. I agree, and was hoping there's an easy solution...
-Kevin
On Mon, Sep 7, 2015 at 5:03 PM, Kevin P Dyer kpdyer@gmail.com wrote:
Response inline.
On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel yawning@schwanenlied.me wrote:
On Mon, 7 Sep 2015 14:37:07 -0700 Kevin P Dyer kpdyer@gmail.com wrote:
...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.
It isn't? It hasn't gotten any updates because nothing broke and the pt spec is relatively static (for now, eventually it'll change and pyptlib will get a flurry of updates as needed).
I was speaking to Brandon Wiley about this last week. I don't want to speak for him, but I remember him saying that it's no longer being developed.
Either way, does pyptlib help solve this issue?
-Kevin
On Mon, 7 Sep 2015 17:03:00 -0700 Kevin P Dyer kpdyer@gmail.com wrote:
Response inline.
On Mon, Sep 7, 2015 at 3:29 PM, Yawning Angel yawning@schwanenlied.me wrote:
On Mon, 7 Sep 2015 14:37:07 -0700 Kevin P Dyer kpdyer@gmail.com wrote:
...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.
It isn't? It hasn't gotten any updates because nothing broke and the pt spec is relatively static (for now, eventually it'll change and pyptlib will get a flurry of updates as needed).
I was speaking to Brandon Wiley about this last week. I don't want to speak for him, but I remember him saying that it's no longer being developed.
Either way, does pyptlib help solve this issue?
It somewhat reduces what you'll need to re-implement but not significantly since you'd still need to re-implement all the stuff that touches the network.
Kevin P Dyer kpdyer@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!
George Kadianakis transcribed 1.4K bytes:
Kevin P Dyer kpdyer@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.
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@torproject.org wrote:
George Kadianakis transcribed 1.4K bytes:
Kevin P Dyer kpdyer@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
-
George Kadianakis -
isis -
Kevin P Dyer -
Yawning Angel