* commit 'tor-0.2.1.16-rc': (31 commits)
Bump version to 0.2.1.16-rc
prepare changelog for 0.2.1.16-rc
Better fix for 997.
Revert "Backport fix for bug 997."
tor-resolve: Don't automatically refuse .onion addresses.
Backport fix for bug 997.
Revise earlier check for correct IPv4 addr length to check for ==4.
Check answer_len in the remap_addr case of process_relay_cell_not_open.
update requirements to openssl 0.9.7
Missing changelog entry about geoip
Move and fix a changelog entry. Noticed by optimist.
Avoid a memory corruption problem related to "private" in DirPolicy.
Update the rest of the geoip file.
Update the geoip file
Fix gprof bottlenecks on exit nodes found by Jacob.
Do not report a node as a "chosen exit" when it is not in fact an exit.
Make the second argument to routerset_contains_extendinfo const
Don't attempt to log messages to a controller from a worker thread.
Clean up a bit of C logic, and fix an erroneous warning.
Consider *ListenAddress when warning about low ports and hibernation
...
If the Tor is running with AutomapHostsOnResolve set, it _is_
reasonable to do a DNS lookup on a .onion address. So instead we make
tor-resolve willing to try to resolve anything. Only if Tor refuses
to resolve it do we suggest to the user that resolving a .onion
address may not work.
Fix for bug 1005.
Fix an edge case where a malicious exit relay could convince a
controller that the client's DNS question resolves to an internal IP
address. Bug found and fixed by "optimist"; bugfix on 0.1.2.8-beta.
Apparently all the stuff that does a linear scan over all the DNS
cache entries can get really expensive when your DNS cache is very
large. It's hard to say how much this will help performance, since
gprof doesn't count time spent in OpenSSL or zlib, but I'd guess 10%.
Also, this patch removes calls to assert_connection_ok() from inside
the read and write callbacks, which are similarly unneeded, and a
little costlier than I'm happy with.
This is probably worth backporting to 0.2.0.
Provide a useful warning when launch_circuit tries to make us use a
node we don't want to use. Just give an info message when this is a
normal and okay situation. Fix for logging issues in bug 984.
Update Standards-Version from 3.8.0 to 3.8.1. No real changes required, we
already support nocheck in DEB_BUILD_OPTIONS since August 2004, and we already
create our var/run directory in the init script (tho we now no longer ship it
either - see above).
No longer inform the user if/when we re-create the /var/run/tor directory in
the init script. With /var/run on tmpfs this is completely normal now so our
message was just noise.
This patch adds a function to determine whether we're in the main
thread, and changes control_event_logmsg() to return immediately if
we're in a subthread. This is necessary because otherwise we will
call connection_write_to_buf, which modifies non-locked data
structures.
Bugfix on 0.2.0.x; fix for at least one of the things currently
called "bug 977".
Tas (thanks!) noticed that when *ListenAddress is set, Tor would
still warn on startup when *Port is low and hibernation is active.
The patch parses all the *ListenAddress lines, and checks the
ports. Bugfix on 0.2.1.15-rc
With the last fix of task 932 (5f03d6c), client requests are only added to
the history when they happen after the start of the current history. This
conflicts with the unit tests that insert current requests first (defining
the start of the client request history) followed by requests in the past.
The fix is to insert requests in chronological order in the unit tests.
If we ever add an event, then set it, then add it again, there will be
now two pointers to the event in the event base. If we delete one and
free it, the first pointer will still be there, and possibly cause a
crash later.
This patch adds detection for this case to the code paths in
eventdns.c, and works around it. If the warning message ever
displays, then a cleverer fix is in order.
{I am not too confident that this *is* the fix, since bug 957 is very
tricky. If it is, it is a bugfix on 0.2.0.}
When we got a descriptor that we (as an authority) rejected as totally
bad, we were freeing it, then using the digest in its RAM to look up its
download status. Caught by arma with valgrind. Bugfix on 0.2.1.9-alpha.
