We need to make sure that the worst thing that a weird consensus param
can do to us is to break our Tor (and only if the other Tors are
reliably broken in the same way) so that the majority of directory
authorities can't pull any attacks that are worse than the DoS that
they can trigger by simply shutting down.
One of these worse things was the cbtnummodes parameter, which could
lead to heap corruption on some systems if the value was sufficiently
large.
This commit fixes this particular issue and also introduces sanity
checking for all consensus parameters.
This was originally a patch provided by pipe
(http://www.mail-archive.com/or-talk@freehaven.net/msg13085.html) to
provide a method for controllers to query the total amount of traffic
tor has handled (this is a frequently requested piece of information
by relay operators).
The spec stated that support for the helper-nodes command would be removed
in 0.1.3.x, however support for this command is still in Tor. Updated the spec
to reflect this and added a node that the command is deprecated.
Several updates to grammars for events and GETINFO results. All relate
to the fact that LongName has replaced ServerID since 0.2.2.1-alpha. See
documentation of VERBOSE_NAMES for more information. The following
grammars were changed:
* orconn-status GETINFO result
* entry-guards GETINFO result
* Path general token
* OR Connection status changed event
* New descriptors available event
In all cases a note was added about when the old grammar applies.
(1) Made the wording of the comments consistant with token names.
Digest/Fingerprint and Name/Nickname were being used interchangeably.
Better to just use Fingerprint and Nickname becuase they are the names
of the tokens.
(2) Places the tokens currently in use before the tokens used in older
versions. ServerSpec should be documented before ServerID.
(3) Added a note to the comments about ServerID that cross reference
the VERBOSE_FEATURE, allowing users to see when and why ServerID was
replaced with LongName.
(1) On by default is a bad way to describe features. Rather, they
are always on and should be viewed as a part of the control
protocol. Updated the wording in USEFEATURE to reflect this.
(2) Made descriptions of Tor versions consistant across all
features. There is the version in which a feature was introduced and
the version in which it became part of the protocol.
(3) Reworded the description of the VERBOSE_NAMES feature. The
previous wording describes the way things used to be first. Better to
lead with the current state of things and then describe how it differs
from old versions.
Having very long single lines with lots and lots of things in them
tends to make files hard to diff and hard to merge. Since our tools
are one-line-at-a-time, we should try to construct lists that way too,
within reason.
This incidentally turned up a few headers in configure.in that we were
for some reason searching for twice.
We decided to no longer ship expert packages for OS X because they're a
lot of trouble to keep maintained and confuse users. For those who want
a tor on OS X without Vidalia, macports is a fine option. Alternatively,
building from source is easy, too.
The polipo stuff that is still required for the Vidalia bundle build can
now be found in the torbrowser repository,
git://git.torproject.org/torbrowser.git.
Instead of rejecting a value that doesn't divide into 1 second, round to
the nearest divisor of 1 second and warn.
Document that the option only controls the granularity written by Tor to a
file or console log. It does not (for example) "batch up" log messages to
affect times logged by a controller, times attached to syslog messages, or
the mtime fields on log files.
