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]
- 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. :)
- 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?
- 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... [3] https://gitweb.torproject.org/stem.git/commit/?id=caee7d6c