This reverts commit 3847f549.

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.

Karsten Loesing authored Jun 16, 2009 and Nick Mathewson committed Jun 16, 2009

Backporting 6a32beb8 and ca8708a9.

We need this to match the check in connection_ap_handshake_socks_resolved().

Found by optimist.

Roger Dingledine authored Jun 12, 2009 and Nick Mathewson committed Jun 12, 2009

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.

This is a posible fix for bug 996.

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.

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

(Simplify "if (cond) return 1; return 0;" to "return cond;", and don't
give a warning when we start with accounting on but dirport off.)

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

Karsten Loesing authored May 27, 2009 and Nick Mathewson committed May 27, 2009

With the last fix of task 932 (5f03d6c5), 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.

Ignore connections two hours after switching from bridge to relay or back.

Basically, all this means is downgrading our warning messages to debug
messages, since the bug workaround code here is adequate to stop the
bug.

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

Roger Dingledine authored May 17, 2009 and Nick Mathewson committed May 17, 2009

and cert from disk. Bugfix on 0.2.0.1-alpha.

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.