Hi everyone!
I'm really excited to announce I'll be working on stem for the 2018 Tor Summer of Privacy! The news is still sinking in.
This is going to be my first major chunk of contributing code back to the Tor community. :)
In particular, I'll be working on expanding stem's support to act as a Tor client, aka stem.client, speaking with Tor's ORPort. You can see more about stem in general [1], and read concepts for stem.client [2], but at the end of this email I list my high-level plan for the summer project.
There's definitely more to a Tor client than one can write in a summer, so my focus is on getting basic client functionality and on fetching v2/v3 Onion Service descriptors. The official project period is May 14th through August 21.
My existing work on stem is available by querying through Trac [3] (easier for context) and browsing patches on GitHub [4].
I've been pretty active on IRC recently, but I wanted to broaden this. Anyone is welcome to reach out to me with questions/comments!
On OFTC and Trac, I'm dmr. I plan to attend the network team meetings [5] (at least lurk) to get a sense of Tor's protocol development and to be around for any littlet-tor/stem syncing discussions.
I'll also be sending updates biweekly to the tor-dev mailing list and writing "/me status: [...]" posts in #tor-dev.
Lastly, my mentors for the project are atagar and teor.
Really looking forward to this!
Cheers! Dave
-- My high-level plan is the following in this rough order: * continue prework with stem and the tor specs * get a stronger feel for / strengthen the CI testing for stem * better understand the ecosystem of projects that use stem * begin official coding by tackling minor stem.client improvements and implementing classes for a few more Cell types * continue developing stem.client.Relay and adding further testing using more of the Cell classes already defined * work on relay authentication * move onto fetching relay descriptors from the ORPort * work on the RELAY_EXTEN[sion] cells, to build multi-hop circuits * build upon this to allow actual exit traffic, including implementing RELAY_RESOLVE[D] * work on fetching v2 Onion Service descriptors, since I already have familiarity [6] with that spec, and v2 Onion Services probably will be around for a while yet * work on fetching v3 Onion Service descriptors * work on other stem.client improvements, if time allows * culminate the project with tutorials and a blog post introducing the new user-facing features of stem
[1] https://stem.torproject.org/ [2] https://www.torproject.org/getinvolved/volunteer.html.en#pythonTorClient [3] https://trac.torproject.org/projects/tor/query?cc=~dmr&or&reporter=d... ^ a bit noisy, sorry; look at "Core Tor" [4] https://github.com/dmr-x/stem [5] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam#Meetings... [6] https://github.com/dmr-x/talks
Dave Rolek dmr-x@riseup.net writes:
Hi everyone!
Hi Dave,
Congratulations on your project/acceptance!
In particular, I'll be working on expanding stem's support to act as a Tor client, aka stem.client, speaking with Tor's ORPort. You can see more about stem in general [1], and read concepts for stem.client [2], but at the end of this email I list my high-level plan for the summer project.
I don't know if you've gotten far enough to discuss code layout/design, but it would be really cool if you follow the "sans-IO" approach for the design of the actual "OR protocol" part of the project.
A great example of this is the Hyper/H2 libraries by Cory Benfield for the HTTP2 protocol -- this what drives Twisted HTTP2 support as well as threaded (blocking I/O) servers.
https://github.com/python-hyper/hyper-h2
There are several advantages to this approach:
- makes for a nice and clean separation between core "protocol stuff" and the I/O. - the above makes testing easier and cleaner (e.g. end-to-end tests that don't use any "real networking", all in-memory) - allows use in blocking / threaded implementations but also async (event-based) implementations (for example, someone could then leverage the bulk of your work to make an asyncio binding without having to re-write all the parsing and state-machine code) - it's the new hotness
I'm usually idling in #tor-dev as meejah, ping me any time
Good luck with your project, sounds interesting!
-
Dave Rolek -
meejah