TODO

- Roadmap and completed work for next release (1.4.1)
  [ ] refactor panels
      Currently the interface is a bit of a rat's nest (especially the
      controller). The goal is to use better modularization to both simplify
      the codebase and make it possible to use smarter caching to improve
      performance (far too much is done in the ui logic). This work is in
      progress - /init and /util are done and /interface is partly done. Known
      bugs are being fixed while refactoring.
      
      [ ] conn panel
        - expand client connections and note location in circuit (entry-exit)
        - for clients give an option to list all connections, to tell which are
          going through tor and which might be leaking
        - check family members to see if they're alive (VERSION cell
          handshake?)
        - fallback when pid or connection querying via pid is unavailable
          List all connections listed both by netstat and the consensus
        - note when connection times are estimates (color?), ie connection
          was established before arm
        - connection uptime to associate inbound/outbound connections?
        - identify controller connections (if it's arm, vidalia, etc) with
          special detail page for them
        - provide bridge / client country / exiting port statistics
          Include bridge related data via GETINFO option (feature request
          by waltman and ioerror).
        - pick apart applications like iftop and pktstat to see how they get
          per-connection bandwidth usage. Forum thread discussing it:
          https://bbs.archlinux.org/viewtopic.php?pid=715906
      [ ] control port interpreter (interactive prompt)
          Panel and startup option (-t maybe?) for providing raw control port
          access along with usability improvements (piggybacking on the arm
          connection):
          - irc like help (ex "/help GETINFO" could provide a summary of
            getinfo commands, partly using the results from
            "GETINFO info/names")
          - tab completion and up/down for previous commands
          - warn and get confirmation if command would disrupt arm (for
            instance 'SETEVENTS')
          - 'safe' option that restricts to read-only access (start with this)
          - issue sighup reset
      [ ] low hanging fruit from the "client mode use cases" below
  * release prep
    * pylint --indent-string="  " --disable=C,R interface/foo.py | less
    * double check __init__.py and README for changes

- Roadmap for version 1.4.2
  [ ] refactor panels
      [ ] controller and popup panels
      [ ] attempt to clear controller password from memory
        - http://www.codexon.com/posts/clearing-passwords-in-memory-with-python
  * release prep
    * pylint --indent-string="  " --disable=C,R interface/foo.py | less
    * double check __init__.py and README for changes

- Roadmap for version 1.3.9
  [ ] refactor panels
      [ ] controller and popup panels
        - allow arm to resume after restarting tor
            This requires a full move to the torTools controller.
        - provide measurements for startup time, and try to improve bottlenecks
  [ ] menus
      - http://gnosis.cx/publish/programming/charming_python_6.html ?
      - additional options:
        - make update rates configurable via the ui
        - dialog with flag descriptions and other help
        - menu with all torrc options (making them editable/toggleable)
  [ ] setup scripts for arm
      [ ] updater (checks for a new tarball and installs it automatically)
        - attempt to verify download signature, providing a warning if unable
          to do so
      [ ] look into CAPs to get around permission issues for connection
          listing sudo wrapper for arm to help arm run as the same user as
          tor? Irc suggestions:
            - man capabilities
            - http://www.linuxjournal.com/article/5737

- Bugs
  * Log deduplication is currently an n^2 operation. Hence it can't handle
    large logs (for instance, when at the DEBUG runlevel). Currently we're
    timing out the function if it takes too long, but a more efficient method
    for deduplication would be preferable.
  * when in client mode and tor stops the header panel doesn't say so
  * util are assuming that tor is running under the default command name
      attempt to determine the command name at runtime (if the pid is available
      then ps can do the mapping)
  * util/torTools.py: effective bandwidth rate/burst measurements don't take
      SETCONF into consideration, blocked on:
      https://trac.torproject.org/projects/tor/ticket/1692
  * log prepopulation fails to limit entries to the current tor instance if
      the file isn't logged to at the NOTICE level. A fix is to use the
      timestamps to see if it belongs to this tor instance. This requires
      tor's uptime - blocked on implementation of the following proposal:
      https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/173-getinfo-option-expansion.txt
  * the STATUS_SERVER event may not be supported
      18:52 < mikeperry> atagar: I believe there is no event parsing for STATUS_SERVER
      18:53 < mikeperry> atagar: see TorCtl.EventSink and classes that inherit from it
      18:54 < mikeperry> specifically, TorCtl.EventHandler._decode1, _handle1, and _map1
  
  * conn panel:
    * *never* do reverse dns lookups for first hops (could be resolving via
      tor and hence leaking to the exit)
    * If there's duplicate family entries (and harder case: both nickname and
      fingerprint entries for the same relay) then the duplicate should be
      removed. This is also causing a bad scrolling bug where the cursor can't
      get past the pair of duplicate entries.
    * revise multikey sort of connections
        Currently using a pretty ugly hack. Look at:
        http://www.velocityreviews.com/forums/
          t356461-sorting-a-list-of-objects-by-multiple-attributes.html
        and check for performance difference.
    * replace checks against exit policy with Mike's torctl version
        My version still isn't handling all inputs anyway (still need to handle
        masks, private keyword, and prepended policy). Parse it from the rest
        of the router if too heavy ("TorCtl.Router.will_exit_to instead").
    * avoid hostname lookups of private connections
        Stripped most of them but suspect there might be others (have assertions
        check for this in a debug mode?)
    * connection uptimes shouldn't show fractions of a second
    * connections aren't cleared when control port closes

- Future Features
  * client mode use cases
    * not sure what sort of information would be useful in the header (to
      replace the orport, fingerprint, flags, etc)
      * one idea by velope:
        "whether you configured a dnsport, transport, etc. and whether they
        were successfully opened. might be nice to know this after the log
        messages might be gone."
        [notice] Opening Socks listener on 127.0.0.1:9050
        [notice] Opening Transparent pf/netfilter listener on 127.0.0.1:9040
        [notice] Opening DNS listener on 127.0.0.1:53
    * rdns and whois lookups (to find ISP, country, and jurisdiction, etc)
      To avoid disclosing connection data to third parties this needs to be
      an all-or-nothing operation (ie, needs to fetch information on all
      relays or none of them). Plan is something like:
        * add resolving/caching capabilities to fetch information on all relays
          and distil whois entries to just what we care about (hosting provider
          or ISP), by default updating the cache on a daily basis
        * construct tarball and make this available for download rather than
          fetching everything at each client
        * possibly make these archives downloadable from peer relays (this is a
          no-go for clients) via torrents or some dirport like scheme
    * look at Vidalia and TorK for ideas
    * need to solicit for ideas on what would be most helpful to clients
    * dialog with bridge statuses (idea by mikeperry)
      https://trac.vidalia-project.net/ticket/570
      https://trac.torproject.org/projects/tor/ticket/2068
  * feature parity for arm's config values (armrc entries)
    * editability
    * parse descriptions from the man page? autogeneration of the man page from
      something storing the descriptions
  * handle mutiple tor instances
    * screen style (dialog for switching between instances)
    * extra window with whatever stats can be aggregated over all instances
  * option to save the current settings to the config
    * provide warning at startup if the armrc doesn't exist, with instructions
      for generating it
  * email alerts for changes to the relay's status, similar to tor-weather
    * simple alert if tor shuts down
    * accounting and alerts for if the bandwidth drops to zero
    * daily/weekly/etc alerts for basic status (log output, bandwidth history,
        etc), borrowing from the consensus tracker for some of the formatting
  * mac installer
    * Couple of options include macport and dmg...
      * macport (http://guide.macports.org/#development)
        Build-from-source distribution method (like BSD portinstall). This has
        been suggested by several people.
        
      * dmg (http://en.wikipedia.org/wiki/Apple_Disk_Image)
        Most conventional method of software distribution on mac. This is just
        a container (no updating/removal support), but could contain an icon
        for the dock that starts a terminal with arm. This might include a pkg
        installer.
      
      * mpkg (http://pypi.python.org/pypi/bdist_mpkg/)
        Plugin for distutils. Like most mac packaging, this can only run on a
        mac. It also requires setuptools:
        http://www.errorhelp.com/search/details/74034/importerror-no-module-named-setuptools
  * tab completion for input fields that expect a filesystem path
  * look through vidalia's tickets for more ideas
    https://trac.vidalia-project.net/
  * look into additions to the used apis
    * curses (python 2.6 extended?): http://docs.python.org/library/curses.html
    * new control options (like "desc-annotations/id/<OR identity>")?
  * look into better supporting hidden services (what could be useful here?)
  * provide option for a consensus page
    Shows full consensus with an interface similar to the connection panel.
    For this Mike's ConsensusTracker would be helpful (though boost the
    startup time by several seconds)
  * show qos stats
    Take a look at 'linux-tor-prio.sh' to see if any of the stats are 
    available and interesting.
  * escaping function for uiTools' formatted strings
  * switch check of ip address validity to regex?
    match = re.match("(\d*)\.(\d*)\.(\d*)\.(\d*)", ip)
    http://wang.yuxuan.org/blog/2009/4/2/python_script_to_convert_from_ip_range_to_ip_mask
  * setup wizard for new relays
    Setting the password and such for torrc generation. Maybe a netinstaller
    that fetches the right package for the plagform, verifies signatures, etc?
    (idea by ioerror)
  * audit what tor does
    * Provide warnings if tor connections misbehaves, for instance:
      * ensuring ExitPolicyRejectPrivate is being obeyed
      * check that ExitPolicy violations don't occur (not possible yet since
        not all relays aren't identified)
      * check that all connections are properly related to a circuit, for
        instance no outbound connections without a corresponding inbound (not
        possible yet due to being unable to correlate connections to circuits)
    * check file descriptors being accessed by tor to see if they're outside a
        known pattern
  * script that dumps relay stats to stdout
    Derived from an idea by StrangeCharm. Django has a small terminal coloring
    module that could be nice for formatting. Could possibly include:
      * desc / ns information for our relay
      * ps / netstat stats like load, uptime, and connection counts, etc
  * implement control-spec proposals:
    * https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/172-circ-getinfo-option.txt
    * https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/173-getinfo-option-expansion.txt
  * gui frontend (gtk?)
    Look into if the arm utilities and codebase would fit nicely for a gui
    controller like Vidalia and TorK.
  * unit tests
    Primarily for util, for instance 'addfstr' would be a good candidate.
  * python 3 compatibility
    Currently blocked on TorCtl support.

