Now a user who changes only NumEntryGuards will get the behavior she
expects. Fixes bug 9354; bugfix on 0.2.4.8-alpha.

This implements "algorithm 1" from my discussion of bug #9072: on OOM,
find the circuits with the longest queues, and kill them.  It's also a
fix for #9063 -- without the side-effects of bug #9072.

The memory bounds aren't perfect here, and you need to be sure to
allow some slack for the rest of Tor's usage.

This isn't a perfect fix; the rest of the solutions I describe on
codeable.

We can wait for 0.2.5 for a full rewrite.  #8964

doc/TODO and doc/spec/README were placeholders to tell people where to
look for the real TODO and README stuff -- we replaced them years ago,
though.

authority-policy, v3-authority-howto, and torel-design.txt belong in
torspec.  I'm putting them in attic there since I think they may be in
large part obsolete, but someone can rescue them if they're not.

translations.txt is outdated, and refers to lots of programs other
than Tor.  We have much better translation resources on the website
now.

tor-win32-mingw-creation.txt is pending review of a revised version
for 0.2.5 (see ticket #4520), but there's no reason to ship this one
while we're waiting for an accurate version.

the tor-rpm-creation.txt isn't obsolete AFAIK, but it belongs in
doc/contrib if anywhere.

Resolves bug #8965.

Spotted on tor-talk by "hamahangi".

This might be necessary if the bug8117 fix confuses any applications.

Also add a changes file.

This adds a new option to fix bug 8508 which broke chutney
networks. The bug was introduced by 317d16de.

Mike believes that raising the default to 2 months with no way to lower
it may create horrible load-balancing issues.

Fixes 8240.

(Don't actually increase the default guard lifetime. It seems likely to
break too many things if done precipitiously.)

Fixes bug #7766.

Patch by David Fifield, revised by Peter Palfrader.

fix for bug 7768

resolves ticket 8443.

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.