[tor-bugs] #9815 [Obfsproxy]: Pluggable transports should learn Tor's data directory

[Tor Bug Tracker & Wiki]

#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