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.

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.

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.

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.

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

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 81eee0ec; found by
lodger; uploaded to trac by rransom.  Bug 2363.  Fix on 0.2.2.6-alpha.

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