* commit 'tor-0.2.2.21-alpha': (60 commits)
  fold in another set of changes
  add in missing changelog entries
  0.2.1.29 changelog and blurb
  fold in more changes entries
  repeat overlapping changelog entries
  bump to 0.2.2.21-alpha
  Fix a couple of non-cleared key issues in hidden services
  Zero out some more key data before freeing it
  Update the spec with the new bounds
  Tighten accepted circwindow parameters
  Provide constant limits for all consensus params
  Fix a typo spotted by Roger
  Sanity-check consensus param values
  Make get_net_param_from_list() static
  Add missing check for hostname answer_len in dnsserv size
  clean up message; explain a magic number in a comment
  make the description of tolen_asserts more dire
  Fix a heap overflow found by debuger, and make it harder to make that mistake again
  Always nul-terminate the result passed to evdns_server_add_ptr_reply
  catch another overlong malloc possibility. found by cypherpunks
  ...

we need to do more hunting, but this fixes the ones mentioned in 2385.

Found by cypherpunks; fixes bug 2384.

Based on discussion in bug 2317, these values seem to be sane.

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

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 prepares for making the accessor method for consensus parameters
safer in the next commit.

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

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

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

We have a CVE # for this bug.

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)

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.

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.