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

[Nick Mathewson]

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
      https://gitweb.torproject.org/tor.git/blob/refs/heads/release-0.2.4:/ChangeLog
    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
    changelog at
      https://gitweb.torproject.org/tor.git/blob/refs/heads/master:/ChangeLog
    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:
      https://gitweb.torproject.org/user/nickm/tor-roadmaps.git
    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.