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

Found by cypherpunks; fixes bug 2384.

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.

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.

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.

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

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.

Fixes bug 2331.

Spotted by doors, fixes bug 2326.

Fixes bug 2324.

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.

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

Fixes bug 2156.

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

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.

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.

Bugfix on 0.1.1.1-alpha; found by boboper.

Also add a changes file

Reported by an anonymous commenter on Trac.