Our regular DH parameters that we use for circuit and rendezvous
crypto are unchanged.  This is yet another small step on the path of
protocol fingerprinting resistance.

Found by piebeer.

This patch imposes (very long) limits on the length of a line in a
directory document, and on the length of a certificate.  I don't
think it should actually be possible to overrun these remotely,
since we already impose a maximum size on any directory object we're
downloading, but a little defensive programming never hurt anybody.

Roger emailed me that doorss reported these on IRC, but nobody seems
to have put them on the bugtracker.

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.