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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev