This is based on shitlei's fix for bug2629, with extra parens removed.
Fixes bug 2629, bugfix on 0.2.1.2-alpha.

We need to _REJECT_ descriptors with accept6/reject6 lines.  If we
let them onto the network , other un-upgraded tors will crash.

This reverts commit b3918b3b.

This fixes a remotely triggerable assert on directory authorities, who
don't handle descriptors with ipv6 contents well yet. We will want to
revert this once we're ready to handle ipv6.

Issue raised by lorth on #tor, who wasn't able to use Tor anymore.
Analyzed with help from Christian Fromme. Fix suggested by arma. Bugfix
on 0.2.1.3-alpha.

We want to use the discard port correctly, so a htons() was missing.
Also we need to set it correctly depending on address family.

Review provided by danieldg

The third argument for connect should be dependent on the address
family. Issue spotted by piebeer who also wrote the patch.

This should fix a bug that special ran into, where if your state file
didn't record period maxima, it would never decide that it had
successfully parsed itself unless you got lucky with your
uninitialized-variable values.

This patch also tries to improve error messags in the case where a
maximum value legitimately doesn't parse.

Rename the _UsingTestingTorNetwork hidden option to
_UsingTestNetworkDefaults (thanks Nick for the suggestion) and added a
changes file.

also log about running changes, even on a bridge authority.

In private networks, the defaults for some options are changed. This
means that in options_validate(), where we're testing that the defaults
are what we think they are, we fail. Use a workaround by setting a
hidden configuration option _UsingTestingTorNetwork when we have altered
the configuration this way, so that options_validate() can do the right
thing.

Fixes bug 2250, bugfix on 0.2.1.2-alpha (the version introducing private
network options).

Patch from "postman" on trac. Fixes bg 2366. Bug on 0.1.2.5-alpha.

Fixes bug 2572.

Once again spotted by mobmix

Also add a changes file for the fix

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.

(Backport from 0.2.2's 5ed73e38)

Fixes #2408.

Patch our implementation of tor_lockfile_lock() to handle this case
correctly. Also add a note that blocking behaviour differs from windows
to *nix. Fixes bug 2504, issue pointed out by mobmix.

fixes bug 2470

rransom noticed that a change of ORPort is just as bad as a change of IP
address from a client's perspective, because both mean that the relay is
not available to them while the new information hasn't propagated.
Change the bug1035 fix accordingly.

Also make sure we don't log a bridge's IP address (which might happen
when we are the bridge authority).

both noticed by rransom

John Brooks authored 14 years ago and Nick Mathewson committed 14 years ago

Fix for #2358

Suggested by rransom.  Probably necessary for testing network mode.

When calling circuit_build_times_shuffle_and_store_array, we were
passing a uint32_t as an int.  arma is pretty sure that this can't
actually cause a bug, because of checks elsewhere in the code, but
it's best not to pass a uint32_t as an int anyway.

Found by doorss; fix on 0.2.2.4-alpha.

We detect and reject said attempts if there is no chosen exit node or
circuit: connecting to a private addr via a randomly chosen exit node
will usually fail (if all exits reject private addresses), is always
ill-defined (you're not asking for any particular host or service),
and usually an error (you've configured all requests to go over Tor
when you really wanted to configure all _remote_ requests to go over
Tor).

This can also help detect forwarding loop requests.

Found as part of bug2279.

Fixes part of bug 2279.  Bugfix on 0.1.2.1-alpha.

This bug was noticed by cypherpunks; fixes bug 2378.

Bugfix on svn commit r110.