some cleanups. more probably remain, but hey, it's an alpha.

Changes in version 0.1.2.6-alpha - 2007-??-??

  o Minor features (controller):

Changes in version 0.1.2.6-alpha - 2007-01-09

  o Major bugfixes:

    - Fix an assert error introduced in 0.1.2.5-alpha: if a single TLS

      connection handles more than 4 gigs in either direction, we assert.

    - Fix an assert error introduced in 0.1.2.5-alpha: if you're an

      advertised exit node, somebody might try to exit from you when

      you're bootstrapping and before you've built your descriptor yet.

  o Minor bugfixes:

    - Warn if we (as a server) find that we've resolved an address that we

      weren't planning to resolve.

    - Warn that using select() on any libevent version before 1.1 will be

      unnecessarily slow (even for select()).

    - Flush ERR-level controller status events just like we currently

      flush ERR-level log events, so that a Tor shutdown doesn't prevent

      the controller from learning about current events.

  o Minor features (more controller status events):

    - Implement EXTERNAL_ADDRESS server status event so controllers can

      learn when our address changes.

    - Implement BAD_SERVER_DESCRIPTOR server status event so controllers

      about changes to DNS server status.

  o Minor features (directory):

    - Authorities do not recommend exits as guards if this would shift

      excess load to the exit nodes.

  o Major bugfixes:

    - Fix an assert error introduced in 0.1.2.5-alpha: if a single TLS

      connection handles more than 4 gigs in either direction, we assert.

    - Fix an assert error introduced in 0.1.2.5-alpha: if you're an

      advertised exit node, somebody might try to exit from you when

      you're bootstrapping and before you've built your descriptor yet.

  o Minor bugfixes:

    - Restore a warning message if we accidentally resolve an address that

      we weren't planning to resolve.

    - Prevent an (unlikely) bug on 32-bit architectures that could make

      directories send 503s incorrectly when BandwidthBurst plus 2 times

      BandwidthRate was over to 2 GB.

    - Warn that using select() on any libevent version before 1.1 will be

      unnecessarily slow (even for select()).

    - Flush ERR-level status events just like we currently flush ERR-level

      log events, so that a Tor shutdown doesn't prevent the controller from

      learning about current events.

    - Authorities no longer recommend exits as guards if this would shift

      too much load to the exit nodes.

Changes in version 0.1.2.5-alpha - 2007-01-06

  Actions for STATUS_CLIENT severity WARN events can be as follows:

     DANGEROUS_SOCKS

     "PROTOCOL=SOCKS4/SOCKS4a/SOCKS5"

     "PROTOCOL=SOCKS4/SOCKS5"

     "ADDRESS=IP:port"

       A connection was made to Tor's SOCKS port that used a raw IP

       address.  If the client application got this address from

       gethostbyname(), it's leaking target addresses via DNS.

       A connection was made to Tor's SOCKS port using one of the SOCKS

       approaches that doesn't support hostnames -- only raw IP addresses.

       If the client application got this address from gethostbyname(),

       it may be leaking target addresses via DNS.

     SOCKS_UNKNOWN_PROTOCOL

       "DATA=string"

       using Tor as an HTTP proxy?   The DATA is the first few characters

       sent to Tor on the SOCKS port.

     BAD_HOSTNAME

     SOCKS_BAD_HOSTNAME

     [unimplemented]

     // Some application gave us a funny-looking hostname. Perhaps

     // it is broken? In any case it won't work with Tor and the user

     // should know.

     UNRECOGNIZED_ROUTER

     [unimplemented]

     // a nickname we asked for is unavailable. no need for this

     // quite yet, since no end-user controllers let you configure that.

     "HOSTNAME=NAME"

     "METHOD=CONFIGURED/DIRSERV/RESOLVED/INTERFACE/GETHOSTNAME"

       Our best idea for our externally visible IP has changed to 'IP'.

       If 'NAME' is present, we got the new IP by resolving 'NAME'.  If the

       If 'HOSTNAME' is present, we got the new IP by resolving 'NAME'.  If the

       method is 'CONFIGURED', the IP was given verbatim as a configuration

       option.  If the method is 'RESOLVED', we resolved the Address

       configuration option to get the IP.  If the method is 'GETHOSTNAME',

     "STATUS=" "UP" / "DOWN"

     "ERR=" message

        One of our nameservers has changed status.

        // actually notice

     NAMESERVER_ALL_DOWN

        All of our nameservers have gone down.

     ACCEPTED_SERVER_DESCRIPTOR

     "DIRAUTH=addr:port"

        A single directory authority accepted our descriptor.

        // actually notice

  Actions for STATUS_SERVER severity ERR events can be as follows:

     * nameservers have failed' if we're completely out of nameservers;

     * otherwise, the situation is tolerable. */

    warn = 0;

    control_event_server_status(LOG_WARN,

    control_event_server_status(LOG_NOTICE,

                                "NAMESERVER_STATUS NS=%s STATUS=DOWN ERR=%s",

                                ns, escaped(err));

    tor_free(ns);