[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #9815 [Obfsproxy]: Pluggable transports should learn Tor's data directory
#9815: Pluggable transports should learn Tor's data directory
-------------------------+-------------------------------------------------
Reporter: phw | Owner: asn
Type: | Status: needs_revision
enhancement | Milestone:
Priority: normal | Version:
Component: | Keywords: pluggable transport, state
Obfsproxy | location, persistent information
Resolution: | Parent ID:
Actual Points: |
Points: |
-------------------------+-------------------------------------------------
Description changed by phw:
Old description:
> At least ScrambleSuit needs to store persistent information and Tor's
> data directory would be the best place to do that. Right now, however,
> pluggable transports have no way of learning the data directory.
>
> A possible fix for that is in the branch `pass_datadir` in:
> https://github.com/NullHypothesis/obfsproxy
>
> The patches pass the state location (Tor's data directory in managed
> mode) to the pluggable transport's constructor. For external mode, the
> patch adds another command line argument to `pyobfsproxy.py` which allows
> the user to do that manually.
>
> On the plus side, it's an easy fix. On the minus side, it requires
> changing existing transports (even though it's just the constructor's
> method head). An alternative would be yet another method, transports
> would have to implement?
>
> Please let me know if the patches make sense and if I missed anything. I
> could restructure it if you don't like the constructor way. Either way,
> it worked in my tests.
New description:
At least ScrambleSuit needs to store persistent information and Tor's data
directory would be the best place to do that. Right now, however,
pluggable transports have no way of learning the data directory.
A possible fix for that is in the branch `pass_datadir` (which itself is a
branch of `bug8979_draft`) in:
https://github.com/NullHypothesis/obfsproxy
The patches pass the state location (Tor's data directory in managed mode)
to the pluggable transport's constructor. For external mode, the patch
adds another command line argument to `pyobfsproxy.py` which allows the
user to do that manually.
On the plus side, it's an easy fix. On the minus side, it requires
changing existing transports (even though it's just the constructor's
method head). An alternative would be yet another method, transports would
have to implement?
Please let me know if the patches make sense and if I missed anything. I
could restructure it if you don't like the constructor way. Either way, it
worked in my tests.
--
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9815#comment:2>
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