[tor-project] [TSoP] stem.client - status report #2
dmr-x at riseup.net
Wed Jun 13 20:22:21 UTC 2018
This is my second status report for the stem.client TSoP project .
My previous report was posted to the tor-project ml last month. 
This report comes a few days late - sorry about that!
The last few weeks I focused heavily on code review , and a bit on
stem.client architecture .
The outputs of the code review are comments in the Trac ticket 
and stem's first pull request on GitHub , including various bug fixes
 and other improvements [just see 7 for all
The outputs from the architecture task are currently on a private pad.
They'll be shared more widely after some discussion with atagar and
These two tasks have taken more time than I anticipated, so there hasn't
been much else I've done.
## tor protocol, general
For stem.client, I looked at leveraging existing binary
serialization/deserialization libraries. At this time, I've decided none
of them fit well in the scope of stem.client, but I've taken some notes
on them to share later. They may be useful to the wider tor dev
Kaitai Struct  looked the most promising, having a YAML-based
language that helps produce deserialization code in a number of
programming languages. Unfortunately it doesn't presently support
serialization, but it does seem to be a goal of that project.
If time allows for this TSoP project, I'll write up a .ksy definition
just to try it out.
(I also looked a bit at trunnel. Cool stuff!)
# What's next
I'll be waiting on atagar for a bit of feedback, but then probably
implementing some of the architectural changes. I'm excited to do them!
In the interim, I'll be taking care of some of the
not-so-architecture-dependent changes. I'll also be filing and fixing a
few 'dev' tickets, to make development easier.
## tor-spec, readability updates
I started this project work (pre-proposal) diving into the tor-spec 
but admittedly didn't read the tor-design paper  beyond a
glance in the past. So some of the higher-level organization of
communication designs was lost on me.
When I finally realized from the spec that all of a RELAY_CELL payload
is encrypted, not just the data portion, I noted this in IRC, and Roger
pointed me to the paper. Oops! I should've read that long ago.
So I'll be catching up on that while doing further stem.client
Because of this roundabout intro to the communication protocol, I have
some insight into how various tor-spec sections could be improved so
that high-level context is clearer when someone jumps into reading
specific sections of the spec. I'll be collecting this feedback and
submitting clarification patches for review. (As a side note, you can
see I've done this sort of readability improvements on Wikipedia in the
Pre-project, Roger suggested I collect spec updates and submit them for
review en-batch, so I'll plan to do that over the course of the project.
# Other Tor things
Cryptoparty Ann Arbor held a workshop at the local library on Saturday
. It went pretty well! I'm participating in the community meeting
today (happening now in #tor-meeting), so more specific updates will be
I've also welcomed a few new developers to the community, mostly within
#tor-dev. One of them posted to the tor-dev list , so I encourage
you to check it out, if you haven't gotten in touch with Simon off-list
As with before, I've been active and reachable over IRC, where my nick
is dmr. Please don't hesitate to reach out to me via IRC or email!
p.s. I get quite a chuckle out of this commit - gotta have some fun
More information about the tor-project