[tor-reports] Nick's status report for May 2014
nickm at torproject.org
Mon Jun 2 02:06:19 UTC 2014
Over the course of May, I did this stuff:
* Worked with Andrea and others to triage issues for a stable
0.2.4.22 release, and finally put it out: The first Tor stable
release since February, and the first one I did the release for
since I-don't-know-when. See the 0.2.4.22 changelog at
for full info.
* Wrote tons of patches and bugfixes for Tor 0.2.5, and applied
many of them, along with patches from various others. An
0.2.5.5-alpha release should be ready soon. See the draft
for the list so far: nearly everything on that list today was
merged in May.
* Notable items I implemented this month include:
* A zillion fixes to the linux seccomp sandbox code, mostly
found by alphawolf. The ARM compilation fixes come thanks to
schroot help from weasel.
* An authority-side fix for #11743: a tricky attack wherein a
node claiming to have another node's onion key could under
some circumstances keep that node's microdescriptor from
getting used by clients.
* 11750: use siphash24 to avoid hashtable-related DoS in the
* Fixes for a bunch of zlib-related issues that affect the
correctness and compression-level of outputs from Tor's
(micro)descriptor compression logic. (11648, 11787, 11824).
Thanks to wfn, karsten, and atagar for all their work
figuring this stuff out.
* Found a bug in our connection-closing logic (#12023); wrote
a fix to make some kinds of traffic-analysis a little
* Wrote a list of the major items to be done in the Tor program
over the next few years, resources permitting. It lists items
and rough-estimate priorities and times, but not much more:
It's a draft. Don't take it as gospel, or even assume that
it's very well-considered.
* Worked a bit with Daniel Marti to revise proposal 140.
* Investigating binary-parser generators for use transforming the
protocol-description parts of our specifications in to correct
C. (This is probably a good idea, given how many vulnerabilities in
all of the C TLS implementations have been due to hand-written C
* Solicited run-time CPU profiles from relay operators, in order
to see if there are any bottlenecks in 0.2.5.x that we need to
eliminate before release (#11332). So far, I identified two
possibilities, and wrote fixes for both (#12169, #12170).
* Revised proposal 220 based on comments from George K and Nick H.
More information about the tor-reports