[tor-dev] oppy - an Onion Proxy in Python

Wed Jan 21 03:55:25 UTC 2015

Hi Damian,

Thanks for the reply!

> Your codebase mentions that you had trouble with the ExitPolicy's
> can_exit_to() when you omit an address. Could you please provide an
> example of a policy you were having trouble with and the expected
> behavior? From the docs and code it sounds like if you omit an address
> it should be permissive. [2][3]

Yes, thanks for the reminder. I meant to do this earlier but apparently
forgot.  I just added an issue on Trac with a more complete description
and code to reproduce: https://trac.torproject.org/projects/tor/ticket/14314

I'm still not actually sure if this is a bug or if I'm just
misinterpreting the documentation.

If it is in fact a bug, I can work on putting together a patch when I
have some time this weekend if you/someone else hasn't gotten to it yet.

> We love seeing alternative tor implementations
> since it gives us the chance to test if specs are up to snuff (Orchid
> is the only other one that comes to mind, but that has been inactive
> since 2013 [1]).

Great!  I actually did find a couple things that were either worded in a
confusing way (I thought) or mistyped in `tor-spec.txt`, and when I have
a few minutes later this week I'll send a patch.

>> 1. Do you think this project is/could be interesting, useful, or
>> potentially beneficial as an addition to the world of Tor software?
>
> Certainly! Always happy for new people to get involved. :)

Cool! I wasn't sure how y'all felt about other implementations, so
that's great to hear. I'll keep hacking on oppy then :) There are a few
(relatively straight-forward) user-facing issues that make it slightly
annoying to use right now, but I think I can fix those pretty easily.

There are a number of more serious core things (e.g. directly affecting
anonymity) that need to be fixed/implemented, however, and that leads to...

>> 2. If so, do you see any major use-cases for oppy?
>
> Interesting ideas. I'm not entirely sure how Oppy dovetails with any
> current work. First thought was 'I wonder if there's anything good to
> merge into Stem'

Now that I think about it, something that would be great to have in Stem
would be path selection capabilities. So something like, say, given a
list of RelayDescriptors and some constraints that must hold for a path,
return some randomly chosen path that satisfies those constraints. A
starting point might be just implementing Tor's default path selection
algorithm with some basic options the caller can configure, but it would
be nice to have the ability to do more novel things too (e.g. build a
path using only exits in country X with the 'BadExit' flag, using only
nodes in \16 Y for the middle position, etc.). This could be pretty cool
from a research/testing standpoint, I think.

One of the next things I need to do for oppy is implement Tor's full
path selection algorithm. However, if you think it would be appropriate,
it'd be great if some of this could eventually just wind up in Stem (so
I could make oppy's code simpler and also so other people could use
these capabilities more easily).

How would you feel about adding path selection capabilities to Stem?

Aside from allowing one to do nice things with descriptors, this could
also work well with some method analogous to
stem.control.Controller.new_circuit() that could do stuff like
auto-choose a path for you based on some desired path attributes the
caller specifies.

oppy has some (very minimal) path selection functionality that can maybe
serve as a starting point, but it has some issues (it was hacked
together pretty quickly to hit course deadlines, it doesn't try to be
efficient, it returns/uses a Twisted deferreds because of how it gets
descriptors, etc.).

I'd be more than happy to work on/help out with this, contribute
code/docs, etc., if you think something along these lines might be
appropriate for inclusion in Stem. I'll need to do this for oppy anyway,
so if you think this might have a place in Stem it'd be nice to
consolidate effort in one place :)

Thoughts?

All the best,
Nik

PS: Thanks for writing/maintaining Stem! It's a really great library and
made writing oppy and working with network status docs and descriptors
*much* simpler.

On 01/20/2015 11:21 AM, Damian Johnson wrote:
> Hi Nik, very nice work! We love seeing alternative tor implementations
> since it gives us the chance to test if specs are up to snuff (Orchid
> is the only other one that comes to mind, but that has been inactive
> since 2013 [1]). Personally I've been curious if we can shift core tor
> to Python, Ruby, or Go for some functionality like descriptor handling
> (C isn't exactly renowned for string parsing, and memory management
> could make things safer), but that's Nick's show and he has good
> reasons for it to be pure C.
> 
> Your codebase mentions that you had trouble with the ExitPolicy's
> can_exit_to() when you omit an address. Could you please provide an
> example of a policy you were having trouble with and the expected
> behavior? From the docs and code it sounds like if you omit an address
> it should be permissive. [2][3]
> 
>> 1. Do you think this project is/could be interesting, useful, or
>> potentially beneficial as an addition to the world of Tor software?
> 
> Certainly! Always happy for new people to get involved. :)
> 
>> 2. If so, do you see any major use-cases for oppy?
> 
> Interesting ideas. I'm not entirely sure how Oppy dovetails with any
> current work. First thought was 'I wonder if there's anything good to
> merge into Stem' and second was 'maybe this could benefit Chutney or
> other core tor work?'. Nick, thoughts?
> 
>> 3. If yes to 1 or 2, would anyone here be interested in hacking on oppy
>> with me? :)
> 
> Personally I try to stay pretty focused on Stem and arm but if this
> treads into those areas I'd be delighted to work with you. Wish you
> the best of luck finding people to collaborate with though - most of
> our projects are one man efforts, and that's unfortunate.
> 
> Cheers! -Damian
> 
> [1] https://subgraph.com/orchid/index.en.html
> [2] https://stem.torproject.org/api/exit_policy.html#stem.exit_policy.ExitPolicy.can_exit_to
> [3] https://gitweb.torproject.org/stem.git/commit/?id=caee7d6c
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150120/701c0149/attachment.sig>