[tor-reports] Nick's status report for May 2014

Nick Mathewson 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 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 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 release should be ready soon. See the draft
    changelog at
    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
        channel,circid->circuit maps.

      * 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
        trickier (#6799).

  * 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
    parsing code.)

  * 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 mailing list