[tor-bugs] #7693 [Stem]: add way to test with traffic through the tor server

[Tor Bug Tracker & Wiki]

#7693: add way to test with traffic through the tor server
-------------------------+--------------------------------------------------
 Reporter:  robinson     |          Owner:  robinson      
     Type:  enhancement  |         Status:  needs_revision
 Priority:  normal       |      Milestone:                
Component:  Stem         |        Version:                
 Keywords:  testing      |         Parent:                
   Points:               |   Actualpoints:                
-------------------------+--------------------------------------------------

Comment(by robinson):

 Replying to [comment:6 atagar]:
 > Hi Sean. Looks good, I pushed some changes to the 'exp-socks5' branch of
 my personal repo - thoughts?

 Thank you for your feedback.  I re-worked my patch set based on your
 comments and I pushed it to a new branch[0].

 > I also had a few questions while reviewing this...
 >
 > * Would something like this be useful for stem users for scripting
 against tor (ie, should we have something like this in stem/socket.py
 instead)? If so then is there something that we can do about the DNS
 leakage that you mentioned? I'm thinking that this might be useful for
 #7505.

 A) No, please resist feature creep.  Stem is a Tor controller library, not
 a general network communications framework.  For proxy use in Python, I
 recommend neehi[1].

 B) I believe it may be possible to capture/re-direct DNS look-ups by
 monkey-patching socket.gethostbyname(), etc.

 > * Can we merge in any remaining useful bits from 'test/util.py', or
 shall we drop external_ip()? It looks to be unused.

 I left test/util.py alone in the new patch set.  We can look at clean-
 up/removal after test/betwork.py is in-use.

 > * Speaking of util.py, the test that used it should probably be fixed
 (integ tests will now break if you give it the ONLINE target)...

 When I tried to fix this using "controller.get_conf()" to find the socks
 information, things went pear-shaped.  With socks-option-related bugs in
 tor 0.2.2.x fixed in 0.2.3.x and option name changes I am unsure how to
 proceed to safely and compatibly set the socks information in the Tor test
 instance.  I'll open a new ticket with details for this topic.

 > * What does the trailing underscore in "type_" indicate and why is there
 an unused "_sock" argument? Do these come from the socket.socket's
 constructor definition?

 The trailing underscore is to avoid a conflict with the built-in type
 function[2].  _sock is a barely documented parameter to allow (I think)
 socket.socket to re-use existing sockets.  It's here just to provide
 compatibility.  But, in my new patch set, I actually use it.

 [0]: https://gitorious.org/stem-robinson/stem-robinson/commits/exp-
 socks5-v2
 [1]: http://pypi.python.org/pypi/neehi  I just released this as a bug-fix
 and modernization release of SocksiPy.
 [2]: single_trailing_underscore_ @ http://www.python.org/dev/peps/pep-0008
 /#descriptive-naming-styles

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7693#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online