Now the manpages no longer refer to tsocks or tsocks.conf, and we no
longer have or ship a tor-tsocks.conf.  The only remaining instances
of "tsocks" in our repository are old ChangeLog and ReleaseNotes
entries, and the torify script saying that it doesn't support tsocks.

Fixes bug 8290.

Fixes bug 7876

Mike Perry authored 12 years ago and Nick Mathewson committed 12 years ago

Also, deprecate the torrc options for the scaling values. It's unlikely anyone
but developers will ever tweak them, even if we provided a single ratio value.

Instead of hardcoding the minimum fraction of possible paths to 0.6, we
take it from the user, and failing that from the consensus, and
failing that we fall back to 0.6.

This is ticket 7706, reported by "bugcatcher."  The rationale here
is that if somebody says 'ExcludeNodes {tv}', then they probably
don't just want to block definitely Tuvaluan nodes: they also want
to block nodes that have unknown country, since for all they know
such nodes are also in Tuvalu.

This behavior is controlled by a new GeoIPExcludeUnknown autobool
option.  With the default (auto) setting, we exclude ?? and A1 if
any country is excluded.  If the option is 1, we add ?? and A1
unconditionally; if the option is 0, we never add them.

(Right now our geoip file doesn't actually seem to include A1: I'm
including it here in case it comes back.)

This feature only takes effect if you have a GeoIP file.  Otherwise
you'd be excluding every node.

The right way to set "MaxOnionsPending" was to adjust it until the
processing delay was appropriate.  So instead, let's measure how long
it takes to process onionskins (sampling them once we have a big
number), and then limit the queue based on its expected time to
finish.

This change is extra-necessary for ntor, since there is no longer a
reasonable way to set MaxOnionsPending without knowing what mix of
onionskins you'll get.

This patch also reserves 1/3 of the onionskin spots for ntor
handshakes, on the theory that TAP handshakes shouldn't be allowed to
starve their speedier cousins.  We can change this later if need be.

Resolves 7291.

Closes bug #7730.

With an IPv6 virtual address map, we can basically hand out a new
IPv6 address for _every_ address we connect to.  That'll be cool, and
will let us maybe get around prop205 issues.

This uses some fancy logic to try to make the code paths in the ipv4
and the ipv6 case as close as possible, and moves to randomly
generated addresses so we don't need to maintain those stupid counters
that will collide if Tor restarts but apps don't.

Also has some XXXX items to fix to make this useful. More design
needed.

This clears up the remaining issue stopping me from closing bug 6297.

This replaces the old FallbackConsensus notion, and should provide a
way -- assuming we pick reasonable nodes! -- to give clients
suggestions of placs to go to get their first consensus.

It seems as if our new build system broke gcov for me.  I've tried to
fix doc/HACKING to describe what I needed to do in order to make it
work again.

(for various values of K), to further reduce confusion about whether
Tor counts in units of memory or fractions of units of memory. Fixes
bug 7054.

Implements ticket 6786.

Also remove some trailing whitespace.

Patch from maker; fixes bug 6024.

Fixes bug 6843; bugfix on 0.2.4.1-alpha.

addresses bug 6605.

The current cutoff is 30KB, but in reality a useful cutoff is probably
more like 50KB or 100KB.

* Add changes/ files.
* Edit the tor-fw-helper manpage.
* Fix check-spaces.
* Add prototype for get_list_of_ports_to_forward().
* Fix tor_parse_long() TCP port range.
* Improve doc. of tor_check_port_forwarding().
* Check for overflows in tor_check_port_forwarding().
* Demote successful port forwarding to LOG_INFO.

Conflicts:
	src/common/address.c
	src/or/circuitbuild.c