Provide constant limits for all consensus params

This addresses Nick's concern about doing non-constant bounds checking
inside networkstatus_get_param().

Fix a typo spotted by Roger

Sanity-check consensus param values

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.

Make get_net_param_from_list() static

This prepares for making the accessor method for consensus parameters
safer in the next commit.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Conflicts:
src/or/routerparse.c
src/or/test.c

Merge branch 'bug2352_obsize' into maint-0.2.1

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Add missing check for hostname answer_len in dnsserv size

This is checked elsewhere too, but let's be RFC-conformant.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Merge branch 'bug2332_part2' into maint-0.2.1

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Merge branch 'bug2324_uncompress' into maint-0.2.1

clean up message; explain a magic number in a comment

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Conflicts:
src/or/config.c
src/or/networkstatus.c
src/or/rendcommon.c
src/or/routerparse.c
src/or/test.c

make the description of tolen_asserts more dire

We have a CVE # for this bug.

Fix a heap overflow found by debuger, and make it harder to make that mistake again

Our public key functions assumed that they were always writing into a
large enough buffer.  In one case, they weren't.

(Incorporates fixes from sebastian)

Always nul-terminate the result passed to evdns_server_add_ptr_reply

In dnsserv_resolved(), we carefully made a nul-terminated copy of the
answer in a PTR RESOLVED cell... then never used that nul-terminated
copy.  Ouch.

Surprisingly this one isn't as huge a security problem as it could be.
The only place where the input to dnsserv_resolved wasn't necessarily
nul-terminated was when it was called indirectly from relay.c with the
contents of a relay cell's payload.  If the end of the payload was
filled with junk, eventdns.c would take the strdup() of the name [This
part is bad; we might crash there if the cell is in a bad part of the
stack or the heap] and get a name of at least length
495[*]. eventdns.c then rejects any name of length over 255, so the
bogus data would be neither transmitted nor altered.

  [*] If the name was less than 495 bytes long, the client wouldn't
     actually be reading off the end of the cell.

Nonetheless this is a reasonably annoying bug.  Better fix it.

Found while looking at bug 2332, reported by doorss.  Bugfix on
0.2.0.1-alpha.

catch another overlong malloc possibility. found by cypherpunks

Fix another instance of "128" in buffers.c.  More bug2330.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Make our replacement INT32_MAX always signed

The C standard says that INT32_MAX is supposed to be a signed
integer.  On platforms that have it, we get the correct
platform-defined value.  Our own replacement, however, was
unsigned.  That's going to cause a bug somewhere eventually.

Merge remote branch 'public/bug2363' into maint-0.2.2

Merge remote branch 'sebastian/bug2337' into maint-0.2.2

Merge branch 'bug2331' into maint-0.2.2

add a missing "not" in bug2331 changelog

Merge branch 'bug2346' into maint-0.2.2

Explain bug2346 fix better based on suggestions from arma

Fix a autoconf warning

Pull up more data when parsing socks messages

Previously, we only looked at up to 128 bytes.  This is a bad idea
since socks messages can be at least 256+x bytes long.  Now we look at
up to 512 bytes; this should be enough for 0.2.2.x to handle all valid
SOCKS messages.  For 0.2.3.x, we can think about handling trickier
cases.

Fixes 2330.  Bugfix on 0.2.0.16-alpha.

Wait 60 minutes before retrying failed state save; bug2346

Always nul-terminate the result passed to evdns_server_add_ptr_reply

In dnsserv_resolved(), we carefully made a nul-terminated copy of the
answer in a PTR RESOLVED cell... then never used that nul-terminated
copy.  Ouch.

Surprisingly this one isn't as huge a security problem as it could be.
The only place where the input to dnsserv_resolved wasn't necessarily
nul-terminated was when it was called indirectly from relay.c with the
contents of a relay cell's payload.  If the end of the payload was
filled with junk, eventdns.c would take the strdup() of the name [This
part is bad; we might crash there if the cell is in a bad part of the
stack or the heap] and get a name of at least length
495[*]. eventdns.c then rejects any name of length over 255, so the
bogus data would be neither transmitted nor altered.

  [*] If the name was less than 495 bytes long, the client wouldn't
     actually be reading off the end of the cell.

Nonetheless this is a reasonably annoying bug.  Better fix it.

Found while looking at bug 2332, reported by doorss.  Bugfix on
0.2.0.1-alpha.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Impose maximum sizes on parsed objects

An object, you'll recall, is something between -----BEGIN----- and
-----END----- tags in a directory document.  Some of our code, as
doorss has noted in bug 2352, could assert if one of these ever
overflowed SIZE_T_CEILING but not INT_MAX.  As a solution, I'm setting
a maximum size on a single object such that neither of these limits
will ever be hit.  I'm also fixing the INT_MAX checks, just to be sure.

Add logic in routerparse to not read overlong private keys

I am not at all sure that it is possible to trigger a bug here,
but better safe than sorry.

Update to the January 1 2011 Maxmind GeoLite Country database.

Add missing parens to evdns_base_resolve_* macros while I am at it

Fix check for failed evdns request creation

When using libevent 2, we use evdns_base_resolve_*().  When not, we
fake evdns_base_resolve_*() using evdns_resolve_*().

Our old check was looking for negative values (like libevent 2
returns), but our eventdns.c code returns 1.  This code makes the
check just test for nonzero.

Note that this broken check was not for _resolve_ failures or even for
failures to _launch_ a resolve: it was for failures to _create_ or
_encode_ a resolve request.

Bug introduced in 81eee0ecfff3dac1e9438719d2f7dc0ba7e84a71; found by
lodger; uploaded to trac by rransom.  Bug 2363.  Fix on 0.2.2.6-alpha.

Describe tor-resolve defaults. Bug 2364.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Remove a loud info log message

Correctly detect and exclude addresses outside of our virtual address range

Found by cypherpunks; fixes more of 2328.  Bug was introduced in 3623a122;
first appeared in 0.2.0.5-alpha.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Merge branch 'bug2328_021' into maint-0.2.1

Notice a little faster if we're running out of virtual addresses

We were not decrementing "available" every time we did
++next_virtual_addr in addressmap_get_virtual_address: we left out the
--available when we skipped .00 and .255 addresses.

This didn't actually cause a bug in most cases, since the failure mode
was to keep looping around the virtual addresses until we found one,
or until available hit zero.  It could have given you an infinite loop
rather than a useful message, however, if you said "VirtualAddrNetwork
127.0.0.255/32" or something broken like that.

Spotted by cypherpunks

Handle a NULL return from addressmap_get_virtual_address

Fix for bug 2328; bugfix on 0.1.2.1-alpha; bug found by doorss.

Fix a double-counting bug in addrmap_get_virtual_address

We were decrementing "available" twice for each in-use address we ran
across.  This would make us declare that we ran out of virtual
addresses when the address space was only half full.

Fix size_t vs unsigned comparison too

Fix a SIZE_T_CEILING check in torgzip.c; noticed by cypherpunks

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Note that Tor requires Automake 1.7. Fixes bug 2305

Detect signed size_t and report an error at configure time.

Fix up size and sign issues in base32 code

Fixes bug 2331.

Detect and disallow compression bombs

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Avoid assertion on read_file_to_str() with size==SIZE_T_CEILING-1

Spotted by doors, fixes bug 2326.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Check size against SIZE_T_CEILING in realloc too.

Fixes bug 2324.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Merge remote branch 'sebastian/bug2314' into maint-0.2.2

Never include pthread.h when building for Windows.

On Windows, we never use pthreads, since it doesn't usually exist,
and when it does it tends to be a little weirdly-behaved.  But some
mingw installations have a pthreads installed, so autoconf detects
pthread.h and tells us about it.  This would make us include
pthread.h, which could make for trouble when the iffy pthread.h
tried to include config.h.

This patch changes compat.h so that we never include pthread.h on
Windows.  Fixes bug 2313; bugfix on 0.1.0.1-rc.

Fix a function formatting warning in rephist.c

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Conflicts:
src/or/routerparse.c

fix whitespace issues

Bump copyright statements to 2011 (0.2.2)

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Conflicts:
src/common/test.h
src/or/test.c

Bump copyright statements to 2011

Fix compile wanrings revealed by gcc 4.5 on mingw

Merge remote branch 'public/bug2060' into maint-0.2.2

Merge remote branch 'rransom/bug2190_the_hard_way' into maint-0.2.2

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Merge remote branch 'public/bug2190_021' into maint-0.2.1

Merge branch 'maint-0.2.1' into maint-0.2.2

put 0.2.1.28 release notes in place too

Merge branch 'maint-0.2.1' into maint-0.2.2

Merge commit 'nickm/fix_security_bug_022' into maint-0.2.2

Merge commit 'nickm/fix_security_bug_021' into maint-0.2.1

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Change gabelmoo's IP address and ports.

Merge remote branch fix_security_bug_021 into fix_security_bug_022

Conflicts:
src/common/memarea.c
src/or/or.h
src/or/rendclient.c

Add a changelog entry

Make payloads into uint8_t.

This will avoid some signed/unsigned assignment-related bugs.

Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2

Conflicts:
src/config/geoip

Have all of our allocation functions and a few others check for underflow

It's all too easy in C to convert an unsigned value to a signed one,
which will (on all modern computers) give you a huge signed value.  If
you have a size_t value of size greater than SSIZE_T_MAX, that is way
likelier to be an underflow than it is to be an actual request for
more than 2gb of memory in one go.  (There's nothing in Tor that
should be trying to allocate >2gb chunks.)

Base SIZE_T_CEILING on SSIZE_T_MAX.

Only add each log message to pending_cb_messages once.

Don't call flush_pending_log_callbacks while logging LD_NOCB messages.

Found by boboper.

Update to the December 1 2010 Maxmind GeoLite Country database.

Merge branch 'bug2081_followup_022' into maint-0.2.2

Reject relay versions older than 0.2.0.26-rc

This was the first version to cache the correct directory information.

Fixes bug 2156.

revise bug2081_followup changelog

Fix a bug in calculating wakeup time on 64-bit machines.

If you had TIME_MAX > INT_MAX, and your "time_to_exhaust_bw =
accountingmax/expected_bandwidth_usage * 60" calculation managed to
overflow INT_MAX, then your time_to_consider value could underflow and
wind up being rediculously low or high.  "Low" was no problem;
negative values got caught by the (time_to_consider <= 0) check.
"High", however, would get you a wakeup time somewhere in the distant
future.

The fix is to check for time_to_exhaust_bw overflowing INT_MAX, not
TIME_MAX: We don't allow any accounting interval longer than a month,
so if time_to_exhaust_bw is significantly larger than 31*24*60*60, we
can just clip it.

This is a bugfix on 0.0.9pre6, when accounting was first introduced.
It fixes bug 2146, unless there are other causes there too.  The fix
is from boboper.  (I tweaked it slightly by removing an assignment
that boboper marked as dead, and lowering a variable that no longer
needed to be function-scoped.)

Add a missing ! to directory_fetches_from_authorities

The old logic would have us fetch from authorities if we were refusing
unknown exits and our exit policy was reject*.  Instead, we want to
fetch from authorities if we're refusing unknown exits and our exit
policy is _NOT_ reject*.

Fixed by boboper.  Fixes more of 2097.  Bugfix on 0.2.2.16-alpha.

Don't crash when accountingmax is set in non-server Tors

We use a hash of the identity key to seed a prng to tell when an
accounting period should end.  But thanks to the bug998 changes,
clients no longer have server-identity keys to use as a long-term seed
in accounting calculations.  In any case, their identity keys (as used
in TLS) were never never fixed.  So we can just set the wakeup time
from a random seed instead there.  Still open is whether everybody
should be random.

This patch fixes bug 2235, which was introduced in 0.2.2.18-alpha.

Diagnosed with help from boboper on irc.

Fix a harmless off-by-one error in counting controller argument lengths

Bugfix on 0.1.1.1-alpha; found by boboper.

Specified grammars for orconn-status and entry-guards for Tor versions 0.1.2.2-alpha through 0.2.2.1-alpha with feature VERBOSE_NAMES turned off.

Correct information about support for guards being called helper nodes.

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.

Correct grammars to reflect that VERBOSE_NAMES is part of the protocol.

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.

Several changes to the way tokens describing servers are documented.

(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.

Clarify description of FEATURES in control-spec.

(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.

Merge branch 'maint-0.2.1' into maint-0.2.2

Conflicts:

doc/Makefile.am