Robert Ransom [Tue, 25 Oct 2011 19:33:21 +0000 (12:33 -0700)]
Add option to give guard flag to relays without the CVE-2011-2768 fix
This way, all of the DA operators can upgrade immediately, without nuking
every client's set of entry guards as soon as a majority of them upgrade.
Until enough guards have upgraded, a majority of dirauths should set this
config option so that there are still enough guards in the network. After
a few days pass, all dirauths should use the default.
Nick Mathewson [Mon, 23 May 2011 20:59:41 +0000 (16:59 -0400)]
Remove the -F option from tor-resolve.
It used to mean "Force": it would tell tor-resolve to ask tor to
resolve an address even if it ended with .onion. But when
AutomapHostsOnResolve was added, automatically refusing to resolve
.onion hosts stopped making sense. So in 0.2.1.16-rc (commit 298dc95dfd8), we made tor-resolve happy to resolve anything.
The -F option stayed in, though, even though it didn't do anything.
Oddly, it never got documented.
Found while fixing GCC 4.6 "set, unused variable" warnings.
Roger Dingledine [Tue, 31 May 2011 03:50:37 +0000 (23:50 -0400)]
stop asserting at boot
The patch for 3228 made us try to run init_keys() before we had loaded
our state file, resulting in an assert inside init_keys. We had moved
it too early in the function.
Now it's later in the function, but still above the accounting calls.
Nick Mathewson [Mon, 23 May 2011 20:38:35 +0000 (16:38 -0400)]
Reinit keys at the start of options_act().
Previously we did this nearer to the end (in the old_options &&
transition_affects_workers() block). But other stuff cares about
keys being consistent with options... particularly anything which
tries to access a key, which can die in assert_identity_keys_ok().
Sebastian Hahn [Tue, 25 Jan 2011 14:28:58 +0000 (15:28 +0100)]
Fix assert for relay/bridge state change
When we added support for separate client tls certs on bridges in a2bb0bfdd5 we forgot to correctly initialize this when changing
from relay to bridge or vice versa while Tor is running. Fix that
by always initializing keys when the state changes.
Nick Mathewson [Fri, 3 Dec 2010 18:37:13 +0000 (13:37 -0500)]
Don't crash when accountingmax is set in non-server Tors
We use a hash of the identity key to seed a prng to tell when an
accounting period should end. But thanks to the bug998 changes,
clients no longer have server-identity keys to use as a long-term seed
in accounting calculations. In any case, their identity keys (as used
in TLS) were never never fixed. So we can just set the wakeup time
from a random seed instead there. Still open is whether everybody
should be random.
This patch fixes bug 2235, which was introduced in 0.2.2.18-alpha.
Sebastian Hahn [Tue, 26 Oct 2010 16:22:04 +0000 (18:22 +0200)]
Properly refcount client_identity_key
In a2bb0bf we started using a separate client identity key. When we are
in "public server mode" (that means not a bridge) we will use the same
key. Reusing the key without doing the proper refcounting leads to a
segfault on cleanup during shutdown. Fix that.
Also introduce an assert that triggers if our refcount falls below 0.
That should never happen.
Nick Mathewson [Thu, 21 Oct 2010 17:54:12 +0000 (13:54 -0400)]
Add some asserts to get_{tlsclient|server}_identity_key
We now require that:
- Only actual servers should ever call get_server_identity_key
- If you're being a client or bridge, the client and server keys should
differ.
- If you're being a public relay, the client and server keys
should be the same.
Nick Mathewson [Tue, 8 Jun 2010 22:10:20 +0000 (18:10 -0400)]
Fix zlib macro brokenness on osx with zlib 1.2.4 and higher.
From the code:
zlib 1.2.4 and 1.2.5 do some "clever" things with macros. Instead of
saying "(defined(FOO) ? FOO : 0)" they like to say "FOO-0", on the theory
that nobody will care if the compile outputs a no-such-identifier warning.
Sorry, but we like -Werror over here, so I guess we need to define these.
I hope that zlib 1.2.6 doesn't break these too.
Nick Mathewson [Thu, 20 Oct 2011 03:14:05 +0000 (23:14 -0400)]
Fix crash when changing node restrictions with DNS lookup in progress
Fixes bug 4259, bugfix on 0.2.2.25-alpha. Bugfix by "Tey'".
Original message by submitter:
Changing nodes restrictions using a controller while Tor is doing
DNS resolution could makes Tor crashes (on WinXP at least). The
problem can be repeated by trying to reach a non-existent domain
using Tor:
.. and changing the ExitNodes parameter through the control port
before Tor returns a DNS resolution error (of course, the following
command won't work directly if the control port is password
protected):
Using a non-existent domain is needed to repeat the issue so that
Tor takes a few seconds for resolving the domain (which allows us to
change the configuration). Tor will crash while processing the
configuration change.
The bug is located in the addressmap_clear_excluded_trackexithosts
method which iterates over the entries of the addresses map in order
to check whether the changes made to the configuration will impact
those entries. When a DNS resolving is in progress, the new_adress
field of the associated entry will be set to NULL. The method
doesn't expect this field to be NULL, hence the crash.
Robert Ransom [Mon, 10 Oct 2011 12:33:53 +0000 (05:33 -0700)]
Update documentation comment for rend_client_reextend_intro_circuit
One of its callers assumes a non-zero result indicates a permanent failure
(i.e. the current attempt to connect to this HS either has failed or is
doomed). The other caller only requires that this function's result
never equal -2.
Karsten Loesing [Tue, 9 Nov 2010 13:18:00 +0000 (14:18 +0100)]
Turn on directory request statistics by default.
Change the default values for collecting directory request statistics and
inlcuding them in extra-info descriptors to 1.
Don't break if we are configured to collect directory request or entry
statistics and don't have a GeoIP database. Instead, print out a notice
and skip initializing the affected statistics code.
Nick Mathewson [Fri, 2 Sep 2011 15:51:49 +0000 (11:51 -0400)]
Look for correct "ar" to cross-compile
For some reason, autoconf doesn't by default have an "AC_PROG_AR" for
this -- possibly it's assumed that any "ar" you have will work
everyplace.
Fixes bug 3909; found by sid77.
This fixes a build issue first present in fdbdb4dc1500, but the bug
(of not using a correct ar) has been in every Tor version ever: it
just didn't matter until then.
Nick Mathewson [Wed, 31 Aug 2011 00:42:51 +0000 (20:42 -0400)]
Use %f with printf-style formatting, not %lf
For printf, %f and %lf are synonymous, since floats are promoted to
doubles when passed as varargs. It's only for scanf that we need to
say "%lf" for doubles and "%f" for floats.
Apparenly, some older compilers think it's naughty to say %lf and like
to spew warnings about it.
Sebastian Hahn [Wed, 10 Aug 2011 17:22:41 +0000 (19:22 +0200)]
Ignore deprecation warnings on OS X
Starting with Lion, Apple decided to deprecate the system openssl. We
can start requiring users to install their own openssl once OS X doesn't
ship with it anymore.
Nick Mathewson [Wed, 20 Jul 2011 17:16:06 +0000 (13:16 -0400)]
Check return value in fmt_addr
Previously, if tor_addr_to_str() returned NULL, we would reuse the
last value returned by fmt_addr(). (This could happen if we were
erroneously asked to format an AF_UNSPEC address.) Now instead we
return "???".